Le précédent article se plaignait de divers défauts supportables (pas d'utilisation des namespaces, du bricolage macroique pour implementer les slots, le moc, pas d'utilisation de STL et un style de codage assez peu 'standard'). Mais là, il assène le coup final, en critiquant la convention de QT/KDE qui consiste à déclarer les widgets à coup de new mais surtout de pas faire de delete puisque c'est fait automatiquement par QApplication.
C'est l'argument final qui le pousse à maintenant abandonner QT/KDE pour regarder Gtk-- (et Gnome--).
Il touche deux mots de Inti, qu'il désapprouve aussi, puisqu'appliquant le même concept de new sans delete de QT.
Qu'en pensez-vous ? j'ai brèvement cherché des réponses dans les ml QT/Inti/Gtk-- sans grand succès. Je trouve cet engagement assez important, puisque DDJ est quand même lu par tout informaticien sérieux qui se respecte.
Aller plus loin
- le sommaire de DDJ d'octobre (2 clics)
- Un exemple simple de programme QT (4 clics)
- convention de codage Inti (3 clics)
- Why Inti instead of Gtk - - (5 clics)
# Pareil
Posté par Manu (site web personnel) . Évalué à 5.
A savoir que les mécanismes objets n'étaient pas utilisés et qu'ils étaient "fait" grace à des macros.
Cela date d'il y a presque 2 ans.
Et je pense qu'il vaut mieux utiliser un truc en pur C qu'on contrôle, plutôt qu'un truc qui se veut objet et dont on doit coutourner les limitations.
[^] # Re: Pareil
Posté par yim yom (site web personnel) . Évalué à 10.
De son côté, Gtk-- utilise SigC++, une librairie de signals. Mais ce n'est pas la seule façon de passer des signaux en Gtk--.
Il y a 3 façons:
- connecter un slot à la main avec libsigc++ (facile et dynamique),
- dériver l'objet, et implémenter les fonctions virtuelles correspondant aux signaux (ULTRA-facile et très beau, mais pas dynamique),
- mettre un callback à la main (euh... bon, mouais, pas glop).
[^] # Re: Pareil
Posté par Guillaume Laurent (site web personnel) . Évalué à 6.
Qt offre les deux premières aussi. Pour la "callback à la main", je ne vois pas trop ce que tu veux dire. Tu parles d'une callback GTK+ en C ? Si oui, il est normal que Qt n'offre pas cette alternative :-).
[^] # Re: Pareil
Posté par Anonyme . Évalué à -1.
Heureusement que la news est passée pour que tu te rendes comptes qu'il fallait mieux programmer dans le language qu'on maitrise le mieux!
QT, c'est du C++ alors je ne vois vraiment pas où ses limitations te génent.
A ta décharge, je dirais que la news (le troll) n'est pas vraiment terrible et que c'est dur de trouver l'inspiration.
[^] # Re: Pareil
Posté par Manu (site web personnel) . Évalué à 1.
[^] # Re: Pareil
Posté par pas_moi . Évalué à 1.
QT, c'est du C++ alors je ne vois vraiment pas où ses limitations te génent.
Pour toi, tout ce qui est en C++ n'a pas de limitation!! Ben essaye de faire des plug-ins reposant sur la librairie PWLib utilisée par OpenH323 ( http://www.openh323.org(...) )... c'est impossible becoz les objets reposent sur une gestion des processus et des entrées/sorties propre à cette librairie (pourtant faite en C++ et fonctionnant très bien sur de nombreux OS) et supposant un ensemble d'objets statics créés uniquement au lancement des applications PWLib (d'où le problème avec les plug-ins). Faudrait voir à pas tout confondre.
[^] # Re: Pareil
Posté par Anonyme . Évalué à 0.
Ben essaye de faire des plugins reposant sur la librairie ACE (http://www.cs.wustl.edu/~schmidt/ACE.html(...))... C'est très possible becoz les objets reposent sur une gestion des entrées sorties particulièrement bien étudiée propre à cette librairie (faite en C++ et fonctionnant très bien sur de nombreux OS) et supposant un ensemble d'objets dynamiquement instantiable à n'importe quel moment de la vie d'une application. On peut les décharger quand on veut aussi.
Na
[^] # Re: Pareil
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
Qt est en C++, les "mécanismes objets" sont ceux de C++, ce qui est refait avec des macros n'est pas dans C++ :-) (hélas).
> Et je pense qu'il vaut mieux utiliser un truc en pur C qu'on contrôle, plutôt qu'un truc qui se veut objet et dont on doit coutourner les limitations.
A quelles limitations penses-tu ?
[^] # Re: Pareil
Posté par Manu (site web personnel) . Évalué à 2.
Je ne connais pas Qt et j'ai surement avancé des choses fausses (des grosses conneries).
Dans mon idée, Qt cachait des mécanismes qu'il voulait faire passer comme étant du C++. Ce qui obligeait le développeur à contourner ces mécanismes en s'apercevant de la chose.
Sales mécanismes ==> limitations.
J'ai surement parlé trop vite.
[^] # Re: Pareil
Posté par Yves BAILLY . Évalué à 4.
Hum, il me semble que c'est le contraire. Qt utilise (presque) toute les fonctionnalités objets du C++ (manque les espaces de nom). Tandis que Gtk+ est un incroyable assemblage de macros : pour s'en convaincre, consultez le code source de n'importe quel programme en Gtk+, vous verrez l'utilisation de macros comme GTK_WIDGET pour réaliser des transtypages infernaux, qui se font naturellement en C++.
Par ailleurs, la création de widgets personnels est assez pénible en Gtk+. C'est d'une facilité déconcertante avec Qt.
Bon, je laisse apparaître ici mon opinion. Lorsqu'il s'agit de choisir entre Gtk+ et Qt, je ne vois que des arguments subjectifs. Techniquement et objectivement, les deux librairies se valent en terme de fonctionnalités. Après, c'est affaire de goût.
Mes 2 euro-cents.
[^] # Re: Pareil
Posté par dams (site web personnel) . Évalué à 3.
Et dans ces cas la, le gtk tire tous les avantages des langages. L'implémentation objet, les closures, namespaces, etc...
[^] # Re: Pareil
Posté par Yves BAILLY . Évalué à 2.
Mais cet aspect, me semble-t-il, n'est pas lié au toolkit, mais plutôt à l'intérêt qu'on lui porte. Et de ce coté, il est clair que Gtk+ est plus apprécié que Qt (à mon avis, plus pour des raisons idéologiques que véritablement techniques).
[^] # Re: Pareil
Posté par Gaël Le Mignot . Évalué à 6.
Le problème est sans doute le même avec d'autres langage d'ailleurs.
[^] # Re: Pareil
Posté par Anonyme . Évalué à -1.
Je vois GTK comme une toolkit C au même titre que Motif, QT une toolkit C++. Si tu aimes le C tu peux utiliser GTK si tu préfère ls C mieux vaut utiliser QT. GTK+ n'est rien qu'une surcouche de surcouche ce qui n'est surement pas la meilleur solution pour avoir quelques choses de propres et pour savoir ce qu'il se passe dans les sous-couches.
Pour ceux qui veulent être maitre de ce qu'ils font il peuvent toujours programmer la XLib directement, je peux leur fournir quelques exemples.
[^] # Re: Pareil
Posté par Gaël Le Mignot . Évalué à 2.
Je trouve ça beaucoup plus clair, et je pense que ça vaut largement son "coût" en nombres de touches à appuyer :)
[^] # Re: Pareil
Posté par peau chat . Évalué à 1.
[^] # Re: Pareil
Posté par Philippe F (site web personnel) . Évalué à 5.
La je ne vois pas pourquoi ? Parce que c'est en majuscule ? En C++, tu peux aussi nommer tes classes en majuscule a ca deviendra aussi lisible!
> En GTK on sait à chaque fois exactement à quel niveau de l'héritage on se situe, et de quelle manière on utilise l'objet en question.
Je ne saisis pas comment le fait d'utiliser une macro te permet de savoir a quel niveau d'heritage tu es.
Et puis en C++, tu fais ca avec un simple cast, pas de soucis, le compilateur travaille pour toi. Pas besoin de "return_if_fail" et autres ajouts pas du tout leger de gtk.
En dehors du moc, qui est un peu surprenant au debut, je n'ai trouve aucun defaut a Qt depuis 2 ans que je l'utilise intensement.
Il me semble d'ailleurs que l'utilisation d'espaces de noms plus intensifs est prevu pour Qt3.
Et le modele memoire de Qt est vraiment tres pratique (a cote de celui de Gtk). C'est presque aussi agreable de coder en c++ avec Qt qu'en python. Alors en PyQt, je vous dis pas!!
[^] # Re: Pareil
Posté par Gaël Le Mignot . Évalué à 2.
> La je ne vois pas pourquoi ? Parce que c'est en majuscule ?
Bien sur que non !
> > En GTK on sait à chaque fois exactement à quel niveau de l'héritage on se situe, et de quelle manière on utilise l'objet en question.
> Je ne saisis pas comment le fait d'utiliser une macro te permet de savoir a quel niveau d'heritage tu es.
C'est le fait que tu doives précisier (via une macro mais là n'est pas le pb) comme tu utilises ton objet.
J'ai un GtkCTree et je veux utiliser une fonction qui se trouve dans les GtkCList, je fais:
gtk_clist_set_column_width(GTK_CLIST(ctree), ...)
Et là on voit tout de suite que j'utilises mon ctree comme une clist (valide car GtkCTree hérite de GtkCList)
[^] # Re: Pareil
Posté par peau chat . Évalué à 1.
ctree.setColumnWidth(...) c'es plus simple que :
gtk_clist_set_column_width(GTK_CLIST(ctree), ...)
Pourquoi devrait-on avoir besoin de savoir que c'est dans la "classe" clist que se trouve la méthode set_column_width ? Le principal est de savoir qu'elle est disponible dans un ctree non ?
En plus je te dis pas la redondance sur la même ligne de code :
gtk_clist_set_column_width(GTK_CLIST(ctree), ...)
[^] # Re: Pareil
Posté par Gaël Le Mignot . Évalué à 1.
Une raison comme ça... c'est plus simple pour chercher dans les docs. Une autre raison? Et bien si je veux changer mon truc de type, je sais que je peux.
> En plus je te dis pas la redondance sur la même ligne de code :
Dans ce cas oui, mais ce n'est pas très génant.
Vaut mieux trop d'informations que pas assez...
[^] # Re: Pareil
Posté par core . Évalué à 4.
# Libérez-les!
Posté par Anonyme . Évalué à 5.
Free the mallocs!
# Comment ça marche ?
Posté par Vivi (site web personnel) . Évalué à 3.
comment ça se passe tout ça ? c'est géré par un garbage collector Qt ?
si oui pourquoi il aime pas ? (l'article n'est pas en ligne il me semble)
[^] # Re: Comment ça marche ?
Posté par PLuG . Évalué à -2.
n'allez pas rajouter toutes les merdes de JAVA (GC) dans C++ !!
le garbage collector c'est une invention pour developpeur fainénant qui au lieu de réflechir au bon moment pour libérer la mémoire préfère qu'un algo s'en charge pour lui. [le premier qui avoue qu'il ne sait pas quand il doit liberer la mémoire, je lui retire son clavier !!]
C'est ce genre de développement opportuniste, qui fait que nos CPU sont puissants mais qu'on n'en profite pas, occupé qu'ils sont a garbage collecter au lieu de calculer !!
[^] # Re: Comment ça marche ?
Posté par Anonyme . Évalué à 3.
[^] # Re: Comment ça marche ?
Posté par PLuG . Évalué à 1.
Evidement tu aura vu le caractere satirique de mon post précédent :-).
Oui il existe certainement des GC efficaces. De mon coté, j'ai déjà vu que les temps de réponse de websphere sont variables ... justement a cause du lancement inopportun du GC de la JVM.
Par contre, c'est sans appel pour moi, il y a pléthore d'outils pour débusquer les memory leak et quand on s'en appercoit d'une fuite mémoire, corriger le bug n'est pas très compliqué ... si l'algo est clair.
Cela nous ammène plus loin:
Pour moi, un dev qui ne trouve pas un memory leak dans son propre code, c'est qu'il ne maitrise pas l'algo qu'il est en train d'implementer. Sinon, trouver ou placer le free() est assez simple.
Seulement on ne veut plus prendre le temps de réflechir, on code à la volée des algos supposés simples mais sans vraiment les maitriser, à coup de modifications par-ci par-la pour obtenir le résultat ...
Bref je m'insurge contre ce mode de développement.
Croyez-vous que nous aurions des outils système performants si personne ne passait un peu de temps à CONCEVOIR avant de coder ? Et bien penser à la libération des ressources lors de la conception c'est pas plus compliqué que le reste !!
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 8.
Non. Il n'y en a pas beaucoup, encore moins qui marchent vraiment bien, et aucun qui soit fiable à 100% (loin de là). Par ailleurs, les meilleurs sont propriétaires, n'existent que sur un nombre réduit de plateformes, et/ou sont très lourds à utiliser.
> Pour moi, un dev qui ne trouve pas un memory leak dans son propre code, c'est qu'il ne maitrise pas l'algo qu'il est en train d'implementer.
Sérieusement, ça fait combien de temps que tu développes ? :-) Sur des vrais projets, pas des jouets de 100 lignes à la maison.
> Et bien penser à la libération des ressources lors de la conception c'est pas plus compliqué que le reste !!
C'est l'un des problèmes les plus complexes qui soit, et même si tu y penses ça ne veut pas dire que tu vas trouver la bonne solution, ni même qu'elle sera simple à appliquer.
Tiens, une discussion amusante sur la question :
http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET(...)
(faite par un chef de projet MS - à lire aussi pour ceux qui croient encore qu'il n'y a que des imbéciles chez MS).
[^] # Re: Comment ça marche ?
Posté par Vivi (site web personnel) . Évalué à -2.
discuss.develop.com/archives/wa.exe?A2=i
Ouais, c'est trés intéressant. Ce qui est marrant, c'est les réponses dans le threads : y'a plein de gens qui râlent mais sans proposer aucune solution.
[^] # Re: Comment ça marche ?
Posté par pas_moi . Évalué à 5.
J'en ai déjà parlé un peu plus haut mais la librairie PWLib, utilisée dans OpenH323 ( http://www.openh323.org(...) ), possède un système de gestion de l'allocation des objets qui permet de vérifier et retrouver les mémory-leaks; de plus, je suis tout à fait d'accord sur le fait que si un programme est bien développé, les memory-leaks ne sont pas durs à trouver.
Pour ce qui est de travailler sur de gros projets, les GC sont avantageux sur les petits développements où l'on ne veut pas s'embêter à gérer la mémoire (y'a des malloc en bash?); plus une appli est grosse, plus il est important de bien gérer la mémoire... Quand je vois le temps que met LimeWire à se lancer et à s'arrêter, et quand je vois le paquet de mémoire qu'il libère quand je quitte, je me dis que les marchants de mémoire et de CPU n'ont pas fini de nous parler de la beauté de Java et de l'avantage du GC en général...
[^] # Re: Comment ça marche ?
Posté par Vivi (site web personnel) . Évalué à 6.
Ce n'est pas toujours une question de mauvaise implémentation du programme : il y a des techniques de programmation pour lesquelles tu es obligé d'utiliser un GC.
Quand on utilises des structures de données persistentes où des morceaux de la structure sont partagés, on peut difficilement s'en passer. C'est notamment le cas des langages fonctionnels : toutes les implémentations de langage fonctionnel que je connais ont un GC.
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 10.
Et d'ailleurs, malloc() c'est pour les cons qui ne savent pas gérér où placer leur données dans la mémoire.
> c'est une invention pour developpeur fainénant qui au lieu de réflechir au bon moment pour libérer la mémoire préfère qu'un algo s'en charge pour lui.
Bien dit. Qu'un ordinateur effectue un travail compliqué et repetitif à la place d'un être humain, mais où va-t-on chercher des idées pareilles. C'est invraisemblable.
D'ailleurs les compilateurs c'est pour les neuneux qui ne savent pas convertir leur code en assembleur.
[^] # Re: Comment ça marche ?
Posté par PLuG . Évalué à 5.
Bien sur que non. Ou ai-je dit cela ?
Ce que je dit c'est que grosso-modo, on devrait trouver au moins autant de free() que de malloc dans le code. C'est très différent. Je ne suis pas contre les variables dynamiques, je suis contre les GC censés savoir mieux que le developpeur QUAND il faut libérer la mémoire. Y a une nuance.
Qu'un ordinateur effectue un travail compliqué et repetitif à la place d'un être humain...
Apparement, tu as besoin d'un cours sur l'optimisation:
1er cas: le developpeur (aidé des outils automatiques qu'il veut) trouve QUAND libérer les ressources et place l'appel a la fonction free() au bon endroit dans son code.
2ieme cas: le développeur utilise un GC pour libérer les ressources quand ils ne les utilises plus.
conséquence:
1er cas exécuté une seule fois pour toute.
2ieme cas exécuté en parallèle du traitement à chaque éxécution.
Je ne te parle pas de coder en assembleur, ou en héxa directement pendant que tu y es, mais de savoir ce que l'on fait.
Quand je fait un malloc(), je sais a quel moment je n'aurai plus besoin de l'espace et je fais le free() qui va bien.
A la rigueur on peut laisser l'OS nettoyer à la mort du process si la zone mémoire est utilisée pendant toute la vie du process [mais c'est crade], mais compter sur un GC je pense que c'est du gaspillage.
[^] # Re: Comment ça marche ?
Posté par Anonyme . Évalué à -2.
Tu sais que gcc utilises un GC ? Tu pourrais peut-etre aller donner un cours d'optimisation à ces gros nuls de développeurs de gcc ... ;-)
mauvais esprit, -1
[^] # Re: Comment ça marche ?
Posté par Anonyme . Évalué à -1.
-1 aussi
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
Mais pourtant tu acceptes qu'une librairie décide pour toi de l'endroit en mémoire où seront tes données, et qu'elle prenne plus de place qu'il n'en faut réellement (malloc() alloue toujours plus que ce que tu lui demande).
> Apparement, tu as besoin d'un cours sur l'optimisation:
Surement, tu as l'air d'être bien plus expérimenté que moi, alors je te fais confiance.
> 1er cas: le developpeur (aidé des outils automatiques qu'il veut)
Quels outils ? T'as un nom, une url ?
> trouve QUAND libérer les ressources et place l'appel a la fonction free() au bon endroit dans son code.
Juste pour info, là on est en C++ donc c'est delete ou delete[].
Bon, un exemple simple : j'ai une classe Fenetre comme ça :
class Fenetre {
public:
const char* nom() { return _nom; }
protected:
char* _nom; // nom de la fenetre
}
Supposons un objet instance de cette classe, et d'autres objets qui appellent Fenetre::nom() et gardent le résultat. L'objet Fenetre doit-il liberer la mémoire occupée par _nom lorsqu'il est lui-même effacé ? Qu'arrive-t-il alors aux autres objets qui ont gardé une copie du pointeur vers _nom ?
> 1er cas exécuté une seule fois pour toute.
En es-tu si sur ? Dans la question précédente, une possibilité est que chaque objet qui a besoin de _nom garde une copie du string, qu'il devra bien sur libérer par la suite, ce qui augmente d'autant les appels à new[]/delete[]. Alors qu'avec un GC, tant qu'il reste un pointeur vers _nom, il ne sera pas libéré...
> 2ieme cas exécuté en parallèle du traitement à chaque éxécution.
Ah non, un GC en général c'est executé soit sur demande expresse du programmeur, soit de manière "chronique" par le runtime (quand le programme ne fait rien, ou qu'il a besoin de ressources).
> Quand je fait un malloc(), je sais a quel moment je n'aurai plus besoin de l'espace et je fais le free() qui va bien.
Tu as surement raison. Je me doute que tu as du travailler sur plusieurs gros projets de quelques centaines de milliers, voire millions de lignes de code, et qu'a chaque fois il était évident pour toi de savoir où liberer sa mémoire.
[^] # Re: Comment ça marche ?
Posté par PLuG . Évalué à 3.
1/ mes propos etaient amplifiés par l'envie de faire réagir.
2/ ton post dans ce sous-thread est le premier a parler de malloc() [d'ou free()dans ma réponse] et "d'utiliser l'ordinateur pour les taches répétitives et simples" [d'ou mon "aidé des outils automatiques"]. De plus, désolé de le dire, mais ce post ne reflétait pas vraiment l'expérience d'un développeur confirmé... d'ou mon ton "moqueur".
Je sais pertinament que les GC ne sont pas mauvais en soit. La tendance actuelle a en mettre de partout est sans doute l'origine de mon premier post ...
Quand je fais du développement, c'est plutôt axé système. Petit daemon proprietaire, portage de midleware ... donc beaucoup de C, peu de C++, mais quand même pas mal de lignes dans certains cas... On implémente tous un jour ou l'autre un compteur de références sur une ressource pour savoir si on peut la libérer ou pas [genre lien hard sur les fichiers]. Je voulais attirer l'attention sur le fait que le GC à un cout non négligeable en termes de perf, et que heureusement il y a bien des projets ou l'on peut s'en passer. L'implémentation "forcée" de GC comme dans java me semble:
1/ puissante
2/ dangereuse puisque utilisée même quand pas necessaire.
Quand on lit l'URL que tu as donné dans l'autre sous-thread, on y voit aussi que le type de MS voudrait bien se passer de GC si il pouvait pour son projet...
Maintenant ton exemple en C++:
OK dans ce ca sil y a dilemne, mais es-tu sur que le modele "objet" de ta fenetre est bon ? Pourquoi des pointeurs vers une chaine interne à l'objet devraient-ils être conservés en dehors de l'objet ? Pourquoi l'objet devrait-il etre détruit avant que les traitements s'y rapportant [ceux qui ont besoin de la chaine] soient terminés ? A mon avis, cet exemple montre un problème de design plus profond...
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Et pourtant, il suffit de regarder l'évolution des langages de programmations au fil des ans pour voir qu'ils sont de plus en plus haut niveau et libèrent le développeur de plus en plus de détails.
> Quand je fais du développement, c'est plutôt axé système
Dans ce cas là je comprends bien qu'un GC te semble inutile et lourd. Mais dans beaucoup d'autres domaines, c'est extrèmement utile.
> Je voulais attirer l'attention sur le fait que le GC à un cout non négligeable en termes de perf, et que heureusement il y a bien des projets ou l'on peut s'en passer.
Personne ne dit le contraire. Maintenant, quand un GC divise par 3 le temps de développement, le cout en perfs tu t'en tapes un peu, il suffit de prendre une machine plus grosse. Ça coute moins cher que de payer tes développeurs 3 fois plus longtemps sur le même truc.
> L'implémentation "forcée" de GC comme dans java me semble
Elle n'est pas forcée, elle est absolument nécéssaire, et tout les futurs langages destinés à occuper la même place que Java auront un GC. Je n'imagine pas qu'un langage ou le programmeur a la charge de la gestion mémoire puisse, si il apparaissait aujourd'hui, avoir un quelconque succès.
> on y voit aussi que le type de MS voudrait bien se passer de GC si il pouvait pour son projet
Il me semble plutôt qu'il voudrait avoir une destruction deterministe dans certains cas. Il conclut que c'est impossible de faire cohabiter ça avec un GC.
> Pourquoi des pointeurs vers une chaine interne à l'objet devraient-ils être conservés en dehors de l'objet ?
Imagine le menu de la liste des fenetres d'un window manager par exemple (bon, c'est pas implémenté comme ça sous X, mais ça pourrait l'être...). Et puis il pourrait y avoir une taskbar aussi, c'est courant. Donc 2 objets différents qui doivent garder un pointeur vers le nom.
Et si tu me dis que la Fenetre devrait signaler à ListeDesFenetres et à Taskbar qu'elle est effacée, ça veut dire que Fenetre contient un pointeur vers ListeDesFenetres et Taskbar, ce qui n'est pas terrible coté encapsulation... Sans compter que pour chaque nouvel objet qui garde un pointeur vers _nom, tu vas devoir modifier l'implémentation de Fenetre. Et je te laisse imaginer la source d'erreurs que cela devient quand tu dépasses les 10 klocs.
La bonne solution est tout simplement d'utiliser std::string (ou QString :-). Mais ça n'est pas toujours aussi simple.
Comme tu le disais, on fait souvent des compteurs de références sur des ressources. C'est un boulot con, systématique, répétitif, et dans lequel il est très facile de faire des erreurs - ou plutôt il est impossible de ne pas en faire. Il est donc normal que la machine le fasse pour toi, c'est son boulot, et contrairement à ce que tu penses elle le fera le plus souvent bien mieux que toi. De la même façon que malloc()/free() ont libéré le programmeur du boulot con qu'était de gerer soi-même les zones mémoires où tu allais loger tes data. C'est pas gratuit, il y a un overhead, malloc va t'allouer 4Kb quand tu lui demande 10 bytes (je dis ça un peu au pif, ça dépend des implémentations), mais tu laisses la machine s'occuper de ça, c'est tout ce qui compte.
[^] # Re: Comment ça marche ?
Posté par peau chat . Évalué à 2.
Un GC, est une entité unique qui gère les allocations mémoires, et les suppressions de références dur les objets afin de les desinstancier quand ils ne sont plus references.
Dans Qt, c'est tout betement un mécanisme d'héritage. Le destructeur d'un objet Qt contient déjà le code consistant à désallouer les objets qui ont été instanciés dans l'objet qui est détruit. C'est du code tout bête avec du delete qui est transmis par héritage. Chaque objet désalloue la mémoire qui dépend de lui. Ce n'est pas un mécanisme centralisé comme un GC.
[^] # Re: Comment ça marche ?
Posté par PLuG . Évalué à 1.
C'est de ma faute (post GC/JAVA) mais j'ai appris pas mal de choses ... C'est la le principal interet des commentaires: voir les différents points de vue sur un sujet, constater que comme d'hab rien n'est blanc ou noir ...
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Il n'y en a pas. Il n'existe pratiquement qu'un GC pour C++, celui de Boehm :
http://www.hpl.hp.com/personal/Hans_Boehm/gc/(...)
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Personne ne dit le contraire :-)
> Dans Qt, c'est tout betement un mécanisme d'héritage.
Non, tu confonds deux concepts.
Un QObject garde la liste de ses "fils" et les efface quand il est lui-même effacé, mais il s'agit de "fils" au sens Qt : new QFoo(parent) -> QFoo est un "fils" de parent.
Même si, de la façon dont c'est implémenté, toutes les classes qui suivent se mécanisme dérivent de QObject (et sont donc parentes au sens héritage C++), il serait possible de faire autrement (mais pas très efficace).
[^] # Re: Comment ça marche ?
Posté par peau chat . Évalué à 1.
Je veux dire par "mécanisme d'héritage" que si le codeur n'a pas besoin de se cogner les delete à la man, c'est parce qu'il y a un ancêtre à son objet qui, dans son destructeur, contient déjà le code qui le fait.
Je voulais surtout signaler que dans le cas de Qt, la libération mémoire se fait par un tout bête "delete object", alors que dans un GC, on doit implémenter des trucs du genre :
getReference(Object)
{
memList[Object].references++;
return memList[Object].pointer;
}
releaseReference(Object)
{
memList[Object].references--;
if (!memList[Object].reference)
{
delete memList[Object].pointer;
removeObjectFromMemList(Object);
}
}
... et tout ça en priant pour qu'à aucun moment le codeur n'ai dupliqué une référence, par exemple en oubliant de surcharger un opérateur d'affectation ...
Bref, en raccourci pour faire simple, dans un cas on gère des pointeurs, dans l'autre des handles.
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
OK, on est d'accord.
> dans un GC, on doit implémenter des trucs du genre
Non, ça c'est du comptage de références. Enfin, techniquement c'est aussi du GC au sens large, mais quand on pense à un GC c'est plutot un truc qui va scanner ta mémoire pour reperer les bouts de mémoire qui ne sont plus utilisés.
[^] # Re: Comment ça marche ?
Posté par Philip Marlowe . Évalué à 2.
Oups! je réponds à Guillaume, au lieu de celui d'avant. Guillaume, SVP, faites passer. Merci.
[^] # Re: Comment ça marche ?
Posté par PLuG . Évalué à -1.
Non, la techno a vapeur est dépassée en terme de perfs. Par contre on pourrait re-parler des moteurs à explosion 2 temps. BEAUCOUP plus performant que les 4 temps qui équipent toutes nos voitures/motos ... mais moins bon en longévité, pollution, ...
<carrement hors sujet>--> -1
<provoc>
gaspiller une ressource parce-qu'elle est de moins en moins chère, c'est précisément le travers de la société de consommation actuelle ou l'on ne répare plus rien et on jette beaucoup. Alors de la à dire que c'est à cause des développeurs fainéants que l'on n'aura bientôt plus de forêt ...
</provoc>
[^] # Re: Comment ça marche ?
Posté par peau chat . Évalué à 8.
comment ça se passe tout ça ?
C'est surtout faux, ou très mal exprimé. Ce n'est pas QApplication qui gère cela mais QObject.
En fait, quand tu instancies un QObject (qui est la classe ancêtre de toutes les autres classes Qt, ou presque), tu fournis en premier paramètre un QObject * parent=0.
Dans le constructeur de QObject, si le *parent est renseigné, alors le parent va être informé qu'il a un "fils" et il va l'ajouter dans une liste.
Lorsqu'un objet d'une classe dérivée de QObject est désinstanciée avec un delete, le destructeur va parcourir la liste de tous les objets fils afin de faire un delete sur chacun d'entre eux.
2 remarques :
* Pourquoi critiquer ce fonctionnement ? Lorsqu'on supprime un père, il faut bien supprimer les fils non ? Alors pourquoi se plaindre du fait que le codeur n'ai pas besoin de pisser systématiquement ces lignes de codes ?
* Si tu t'amuses à instancier tes object sans fournir de *parent , tu auras la joie de devoir tout désinstancier à la main et d'écrire des lignes de codes inutiles...
# Machin dobs un magazine d'informatique ?
Posté par Anonyme . Évalué à -2.
Il faudrait peut-être veiller à ne pas confondre informaticien et développeur. Les premiers font marcher ce que les second essaient de développer.
[^] # Re: Machin dobs un magazine d'informatique ?
Posté par Anonyme . Évalué à -2.
Non non: les premiers essaient de faire marcher ce que les seconds développent.
# Bof...
Posté par Nicolas Roard (site web personnel) . Évalué à 7.
C'est vrai qu'ils pourraient peut être y passer maintenant (?) mais leur truc marche bien, et je ne sais pas si la STL est encore bien supportée partout (enfin y'a des chances maintenant).
Ensuite sa critique sur moc, oui, je suis d'accord, c'est une bidouille. Mais une bidouille sacrèment pratique (je me demande pourquoi ce n'est pas un mécanisme intégré dans C++ ;-). Et faire la même chose à la main, bheu...
Concernant les delete qui sont fait d'office, je ne vois pas trop ce qui le gêne ! et KDE ne s'en porte pas trop mal à priori...
Bref pour moi, malgrès des points intéressants, l'impression que me laisse cette news, c'est quand même un beau troll.
[^] # Re: Bof...
Posté par yim yom (site web personnel) . Évalué à 3.
Quant aux espaces de noms, c'est bien dommage qu'ils ne soient pas utilisés sous Qt/KDE(?), car c'est un mécanisme très pratique, et bien propre (pour une fois ;-).
[^] # Re: Bof...
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Pas pour tout. D'un coté sigc++ permet de connecter un signal a autre chose qu'une méthode, par exemple. Mais d'un autre coté le fait que QObject::connect() utilise des chaines de caractères pour désigner les slots et signaux rend la création dynamique d'UI (à partir d'un fichier de description XML par exemple) extrèmement facile, alors que c'est un casse-tête sans nom avec sigc++.
Ça permet aussi de demander à un objet au runtime quels sont les signaux et les slots qu'il supporte, par exemple (et les properties aussi).
[^] # Re: Bof...
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Je ne connais pas la lib SigC++, si tu as des pointeurs je suis preneur.
<avis personnel>
Ceci dit, je répète qu'à mon avis il faut être pragmatique, Qt marche quand même très bien, et se programme simplement.
Que les mécanismes ne soient pas forcèment sublimes d'un point de vue architectural ne me gêne pas tant que ça, surtout que TrollTech a composé avec les possibilitées existantes quand ils ont commencés leur lib.
Ceci dit, si Gtk-- s'est amélioré, pourquoi pas, mais je trouve qu'on crache un peu vite dans la soupe.
</avis personnel>
[^] # Re: Bof...
Posté par Anonyme . Évalué à 0.
# pfieww super grave
Posté par armage . Évalué à 3.
Je ne sais pas trop comment fonctionne QApplication mais çe ne me paraît pas si grave de faire ça si on a un bon garbage collector.
Java, ça marche comme ça non ?
Et de là à abandonner un langage, ça me parait être un prétexte plutôt qu'une raison rationnelle.
--
armage
[^] # Re: pfieww super grave
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
[^] # RTFA
Posté par Brice Favre (site web personnel) . Évalué à -1.
[^] # Re: RTFA
Posté par Nicolas Roard (site web personnel) . Évalué à 0.
je suis pas abonné à DrDobbs.
[^] # Re: RTFA
Posté par Brice Favre (site web personnel) . Évalué à 1.
[^] # Re: pfieww super grave
Posté par Emmanuel Blindauer (site web personnel) . Évalué à 1.
les deletes qui sont pas a faire a cause du GC, c'est de la fumette!
il n'y a pas besoin de faire de delete que sur el sobjets QT qui sont crée par copie.
par contre si on defini un pointeur sur u objet QT et qu'on fait un new, le delete, c'est pas une option!
pour programmer en qt depuis qques années, si on se passe des deletes, le prg enfle rapidement en memoire.
quadn a moc, je trouve que c'est une solution bien pratique a coté des call back. a coté aussi son histoire de macro, moi j'en connais pas 36 des macros en QT.
par contre en GTK, j'en voie que ca...
[^] # Re: pfieww super grave
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Dans le cas des QObjects et descendants, si. J'ai très souvent ce genre de code :
QVBox *vbox = new QVBox(parent);
new QLabel("un label", vbox);
Pas besoin de garder un pointeur vers le label, il sera libéré avec la vbox.
> pour programmer en qt depuis qques années
Pourtant ce truc là ça se voit assez vite :-).
[^] # Re: pfieww super grave
Posté par peau chat . Évalué à 1.
Je te conseille de jeter un oeil à la documentation Qt, et consulter la classe "Qt". En particulier, regarde l'utilisation du flag "WDestructiveClose".
[^] # Re: pfieww super grave
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
C'est un cas très particulier, les top-levels (typiquement, QMainWindow) n'ayant le plus souvent pas de parent, ça permet là aussi de ne pas avoir à s'occuper de les effacer. Mais ça ne s'applique pas aux QObjects en général (qui ne sont pas forcément des widgets, et encore moins des fenêtres top-level).
[^] # Re: pfieww super grave
Posté par peau chat . Évalué à 1.
Hmmm : http://doc.trolltech.com/2.3/qt.html(...)
"The Qt class is a namespace for miscellaneous identifiers..."
"Inherited by QBrush, QCanvasItem, QCustomMenuItem..."
Si c'est hérité, c'est une "classe" non ? :-)
C'est un cas très particulier, les top-levels (typiquement, QMainWindow
Typiquement aussi les boites de dialogues. Cela permet de les désinstancier de la mémoire lorsque la boite est fermée. Dans les programmes qui gonflent en mémoire, il y a souvent des problemes de boites de dialogues non désinstanciées.
[^] # Re: pfieww super grave
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Oups, exact, je l'avais complètement oubliée. C'est bien implémenté par une classe, mais en pratique ça sert à simuler un namespace. Il n'y a pas de code dedans. Mais bon, tu as raison, c'est bien une classe.
# Ouarf
Posté par Anonyme . Évalué à 1.
Faut pas déconner qd même.
"Le vin de table Grappe Fleurie (TM) est consommé en grande quantité par tout pochetron conciencieux et professionnel"
# Il a tort.
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
Bricolage macroique pour les slots, moc : je pensais la même chose, mais :
- c'est beaucoup plus clair et facile à manipuler que des déclarations de templates (et facile à reconnaitre pour les outils de documentation automatique comme doxygen)
- moc dissimule tout un tas d'autres choses comme les properties, le RTTI spécifique Qt (toujours pratique sur certains compilos braindead), et sans ça les .h seraient illisibles.
Il y a une page complète sur le pourquoi de moc dans la doc de Qt3. Pas encore en ligne malheureusement, il faut downloader une beta pour l'avoir. J'en conseille vivement la lecture à ceux vraiment interessés par la question.
- STL : comme les namespaces, si on veut être portable actuellement il est encore très difficile d'utiliser vraiment la STL. Mais les conteneurs de Qt3 sont compatibles avec la STL, ce qui résout le problème.
- convention Qt/KDE de déclarer les widgets avec 'new' : ben oui, le modèle objet de Qt fait que dans 99,99% des cas, tu n'as pas à te préoccuper de deleter les widgets. Moi c'est plutot le genre d'argument qui m'a énormément séduit quand je suis passé à Qt, parce que ça fait moins de code à écrire, moins de trucs auxquels je dois penser, et donc moins de bugs et des temps de développements plus courts.
C'est à peu près comme si il critiquait Java, Perl ou Python parce qu'il y a un GC dedans.
A noter que Murray Cummings et Karl Nelson, les deux principaux mainteneurs actuels de Gtk--, sont d'accord avec lui sur ce point. Ils n'aiment pas ce principe non plus. Mais lorsque j'ai discuté avec Murray sur ce sujet, il n'a pas su me démontrer que cela l'empéchait effectivement de travailler, et donc il s'agit avant tout d'une question plus esthétique qu'autre chose. La discussion en question :
http://news.gnome.org/993658952/993677931/993691427/993718928/index(...)
[^] # Re: Il a tort.
Posté par Anonyme . Évalué à 0.
Des noms! Des noms!
A ma connaissance Qt tourne sous win, unix et peut-etre mac.
La STL n'est pas supportée par les compilos mac?
idem pour l'utilisation de la STL.
Meme si c'est reimplementé de manière similaire ds Qt, je vois pas l'interet d'avoir 2 fois le meme code en memoire (la STL + le double de Qt) vu que j'utilise la STL.
Sinon, c'est vrai que moc, c'est pas super esthetique :)
Lokh, toujours pas authentifié.
[^] # Re: Il a tort.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
De compilos qui supportent pas les namespaces ? Je dois pouvoir trouver ça, mais bon j'ai un peu la flemme :-).
> A ma connaissance Qt tourne sous win, unix et peut-etre mac.
Pas "peut-être". Qt3 tourne sur OS/X.
> La STL n'est pas supportée par les compilos mac?
Je ne sais pas. Je sais que beaucoup de compilos Unix la digèrent encore assez mal.
> Meme si c'est reimplementé de manière similaire ds Qt, je vois pas l'interet d'avoir 2 fois le meme code en memoire
La STL est une librairies de templates, donc elle ne prend que la place de ce que tu instancies, ce qui est souvent très limité. C'est aussi le cas de la plupart des conteneurs Qt. Et puis au prix actuel du mega, on s'en tape un peu :-).
En plus ça n'est pas le même code, les conteneurs Qt sont un peu moins flexibles mais plus faciles à utiliser (et avec quelques features en plus) que ceux de la STL. Personnellement j'utilise les deux, avec une préférence pour la STL.
> Sinon, c'est vrai que moc, c'est pas super esthetique :)
Compare le .h d'un widget Qt avec celui d'un widget Gtk--, et on en reparle :-).
[^] # Re: Il a tort.
Posté par Gaël Le Mignot . Évalué à 1.
Contrairement aux libraries comme la GLib où le code de g_list_insert() et de g_list_length() n'est qu'une fois pour toute en mémoire (car se trouvant dans la librarie partagée /usr/lib/libglib.so.1.2), dans les bibliothèques de template à la STL, le code source est dans les .h, donc inclus lors de la compilation dans le binaire... Et une fois pas type de données manipulées, bien sur, ce sont des templates.
[^] # Re: Il a tort.
Posté par Sebastien (site web personnel) . Évalué à 1.
Il y a de grandes chances que si, mais Qt ne tourne pas que sur Mac. Qt est compilable avec gcc sur beaucoup d'unix, ainsi qu'avec un certain nombre de compilateurs propriétaires (aCC sur HP, MIPSpro sur Irix, SunCC sur Solaris...) et sur Win32 avec Visual Studio. Et le support de la STL (ou des templates, ou de la bibliothèque standard) est très variable en fonction du compilateur. Visual Studio est très mauvais en template mais a une bonne STL et une assez bonne librairie standard. gcc a un support des templates à peu près supportable, mais une mauvaise librairie standard (locales ? ah non, y'a pas).
Et tout ça est d'actualité alors que Qt a commencé sa vie il y a 4 ou 5 ans ... donc bon ... la STL, ça devient un détail à ce niveau ...
seb.
# pipeau
Posté par Anonyme . Évalué à -7.
reparlera, mais c'est pas demain la veille.
[^] # Re: pipeau
Posté par Anonyme . Évalué à -1.
NE PAS REPONDRE.
TROLL ... TROLL ... TROLL ...
# ni QT ni GTK peut être Win32
Posté par Anonyme . Évalué à -8.
QT pour les raisons en partie évoqué par AS. Pour ma part je reproche surtout le choix du C++.
GTK : c'est pas beau les widgets.
Je regrette sincérement Win32. Je trouve que l'api Win32 est logique, simple, efficace. On peut facilement écrire dans n'importe quel langage (et même en assembleur!). D'ailleurs Win32 n'est pas très loin de X (notamment fonction callback qui gère les événements englobés dans des messages) sauf que Win32 rajoute des possibilités très intéressantes pour la programmation et l'interface GUI (boîtes de dialogues etc.) que ne possède pas X.
Quiconque a vu Win32 sera je pense d'accord avec moi. Cela dit programmer en win32 (avec wine) sous Linux est risqué. Donc quel API GUI?
# Les gouts et les couleurs...
Posté par Yves BAILLY . Évalué à 4.
Bon, bref. On peut toujours jouer les grincheux. Je n'aime pas Gtk+ (pour diverses raisons), mais je reconnais que ça fonctionne plutôt bien. Qt, j'aime beaucoup, et force est de reconnaître que ça marche aussi plutôt bien.
Donc, si cet honorable monsieur n'aime pas le C++ ou les macros (parcequ'en fait, ça revient à ça), hé bien, qu'il change de langage. Toujours facile de critiquer.
[^] # Re: Les gouts et les couleurs...
Posté par Philippe F (site web personnel) . Évalué à 3.
bricolage macrotique ? Les seuls macros que le developpeur utilise dans Qt, c'est:
"slots" -> rien
"signal" -> "protected"
Q_OBJECT -> <on n'a pas besoin de le savoir>
Ca ressemble pas a un bricolage. Et tres vite, on a l'impression que les mot-cles "slots" et "signal" font partie du langage C++.
Ces mot-cles ne sont d'ailleurs utilises que dans le .h et pas dynamiquement. C'est leger et surtout extremement pratique d'avoir tout de declare dans le .h
Cet argument me parait donc encore plus contestable que les autres.
<troll-zone>
Alors que quand je touche a du code Gtk, je tremble a chaque fois que je vois une macro de cast, en imaginant tout ce qu'elle doit faire derriere. Sans compter les "return_if_fail" et autres bidouilles.
Les gens qui disent preferer Gtk parce que "Qt, c'est pas du C++!" me font doucement rigoler. Si un jour je veux absoluement faire du C, une chose est sure, je ne me tournerai pas vers Gtk car ca ne ressemble plus a du C. Ce ressemble plutot un clone hybride de C++.
[^] # Re: Les gouts et les couleurs...
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Y a Q_PROPERTY aussi, moins connu mais quelques fois très utile.
# Il avait aussi critique Gcc
Posté par reno . Évalué à 2.
Le resultat au niveau temps de compilation, taille des binaire gener'e etait sans appel: Visual C++ etait plus rapide et generait des binaires plus petit que Gcc.
Avec en plus les probleme suivants de Gcc avec du C++ standard:
-grosse augmentation du temp de compilation
-le binaire genere est beaucoup plus gros.
Le probleme persistait avec Gcc 3.0...
Ca plus les "problemes" de KDE avec le linker..
Bref, pour le C++, Gcc c'est pas encore vraiment top..
[^] # Re: Il avait aussi critique Gcc
Posté par Anonyme . Évalué à -1.
Non mais!!!
[^] # Bin, c'est un journaliste: il compare..
Posté par Anonyme . Évalué à 2.
- critiquer en faisant des tests comparatifs
- critiquer en étant de mauvaise foi: vi/emacs; KDE/Gnome, etc.
Lui il ferait plutot parti de la première partie..
Je n'ai pas lu l'article sur Qt/KDE donc je n'en parlerai pas, mais pour le comparatif VisualC++/gcc il a pris des critères objectif, et gcc avait des faiblesses..
Son job c'est d'apporter des informations, pas de faire partie d'une religion.
reno
[^] # Re: Il avait aussi critique Gcc
Posté par Philippe F (site web personnel) . Évalué à 3.
Tu corriges ton bug et tu appuies sur F10 (next). Et la, le miracle se produit devant tes yeux:
VC++ recompile automatiquement le fichier que tu viens de modifier, l'integre dans le nouvel executable, le charge en memoire, se transpose au meme endroit, de sorte que tu peux continuer a debugger tranquillement, comme si tu le code sans bug n'avait pas toujours ete la. C'est comme si tu travaillais avec un langage interprete.
Trop fort!!! Ca m'a scie. Dans 10 ans, peut-etre que gcc fera ca. Peut-etre.
Evidemment, ca ne doit pas pouvoir marcher dans tous les cas, mais pour l'instant, j'ai pas eu de problemes.
Je ne m'en suis toujours pas remis tellement c'est pratique.
[^] # Re: Il avait aussi critique Gcc
Posté par Anonyme . Évalué à -1.
# DDJ pour les piliers de bar ???
Posté par jeanphy . Évalué à 2.
Mes secrétaires ont KDE, parce que elles s'y retrouvent...et parce que ça marche bien.
Un décideur Informatique se fout de savoir si c'est écrit en tourtol, mongol, en zgougniachte ou autre: le produit doit répondre à d'autres critères, bien plus sélectifs.
Si tu me trouve un KDE-like très petit et rapide, je suis preneur, meme si c'est mal programmé.
Ce genre de débat est pour programmeurs, au moment de pause ' machine à café'.
ON ferait mieux de définir un BUREAU UNIVERSEL et STABLE, qui soit le meme sous toutes les distributions, destiné à un poste de production.
Non ??
[^] # Re: DDJ pour les piliers de bar ???
Posté par Anonyme . Évalué à 0.
[^] # Re: DDJ pour les piliers de bar ???
Posté par Jak . Évalué à -1.
[^] # Re: DDJ pour les piliers de bar ???
Posté par Thomas RIBO . Évalué à 1.
Une compatibilité entre tous les bureaux de Linux serait le top du top : genre le glisser-déplacer de konqueror dans Nautilus (plus sérieusement, de Konqueror sur un bureau Gnome ou l'inverse), avec l'utilisation de bibliothèques communes.
Mais bon, là, ça tire vers le doux reve, quoiqu'avec un bon bus d'application genre Corba, on doit pouvoir faire des trucs pas mal en mélangeant les genres...
Qui me corrige si je dis une grosse connerie ? ;-)
[^] # Re: DDJ pour les piliers de bar ???
Posté par Anonyme . Évalué à -1.
Ca te va comme correction ou tu veux plus hard??
[^] # Re: DDJ pour les piliers de bar ???
Posté par - - . Évalué à 1.
les gens qui cherchent a savoir quel est la meilleure facon de faire de bon programmes sont les meme gens qui te feront de bon programmes puissants et utiles par la suite.
c'est trés important. extrement important, j ose meme le dire _vital_
(personnellement,jsuis content que gnom et kde vivent tous les 2 ensembles, ils expriment chacun 2 philosophies aussi interessantes l'une que l autre)
(mais quid du projet gnustep et de son langage Objective C ? )
[^] # Re: DDJ pour les piliers de bar ???
Posté par Anonyme . Évalué à -1.
l'homme aux 0 xp ... et qui tient à les garder !
# Mais DDJ aime bien linux
Posté par Brice Favre (site web personnel) . Évalué à 1.
http://www.ddj.com/topics/linux/(...)
# Al Stevens
Posté par jm . Évalué à 3.
http://www.midifitz.com/alstevens/(...)
(avec sa bio et divers articles)
Comme il le remarquait dans une precedente chronique, il fait de "l'open source" depuis longtemps, tout comme DDJ d'ailleurs dont TOUTES les sources des programmes sont publiees et accessibles par ftp.
Quincy, son IDE educatif, dont il se sert pour ses livres, est gratuit ET avec les sources:
http://www.midifitz.com/alstevens/quincy.html(...)
(pour win32)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.