> Je veux dire par "mécanisme d'héritage" que [...]
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.
> Il y a une différence fondamentale en un GC et le mécanisme de Qt.
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).
> De plus, désolé de le dire, mais ce post ne reflétait pas vraiment l'expérience d'un développeur confirmé...
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.
> 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.
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.
> Par contre, c'est sans appel pour moi, il y a pléthore d'outils pour débusquer les memory leak
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.
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 :-).
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.
> A savoir que les mécanismes objets n'étaient pas utilisés et qu'ils étaient "fait" grace à des macros.
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.
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 :-).
> Maintenant, le mécanisme de moc est à mon avis bien moins souple que celui proposé par SigC++.
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).
Namespaces : hélas toujours pas utilisables si on veut être portable dans l'état actuel des compilateurs.
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 :
Pour autant que je sache c'est Thomas qui a raison. Le nom a été trouvé par le gars qui administrait le site ftp ou les sources de la premiere version du kernel on été uploadées.
Linus voulait bien l'appeler "Freax", mais je n'ai jamais vu nulle part que le nom "Linux" vienne de Torvalds lui-même.
> On ne peut donc pas programmer en KDE sans être dépendant de Qt ?
Non.
> Logiquement, dans le boulot de KDE, le but est un peu de faire en sorte que le programmeur qui fait du KDE n'a pas à prendre en compte des considérations de bas niveau (niveau Qt).
Non plus. Qt n'est pas si "bas niveau" que ça.
> Là c'est comme imposer un changement dans le langage C sous prétexte qu'on va faire tourner le programme sur un nouveau processeur.
Non, rien à voir. Qt n'est pas un langage.
> Je ne vois vraiment pas en quoi le passage à Qt3 impose un changement d'API sur KDE, le prochain KDE pourrait tout simplement être capable de se servir de Qt3, son API à lui restant compatible.
Ça voudrait dire wrapper toutes les classes Qt. C'est techniquement possible, mais parfaitement inutile, et le résultat serait mauvais.
Par exemple, dans Qt2 on avait QArray et QVector, maintenant dans Qt3 on a QValueVector et QPtrVector, et leur APIs ont légèrement changé (en mieux). Ces classes sont couramment utilisées dans les libs et les applis KDE. Selon toi, il aura fallu creer KArray et KVector dès le début de KDE pour assurer la compatibilité ? C'est un casse-tête sans nom, et complètement inefficace (tu ne peux plus profiter des améliorations de l'API).
Non, tu n'es pas le seul.
Enfin, je ne sais pas si c'est de l'ultra-libéralisme, plutôt de l'élitisme revendiqué. Mais bon, il faut bien qu'il y en ait encore pour croire et continuer de faire croire que l'Open Source est plein de programmeurs surdoués.
Il y en a, c'est vrai, mais c'est pas la majorité :-).
> En fait, il semble que le passage à 3.x soit fait pour suivre Qt.
Voilà. Qt passe à la version 3 parce que la nouvelle API est incompatible avec la version 2. Il va donc en être de même avec l'API de KDE puisqu'elle est basée sur Qt.
L'incrémentation du numéro de version majeur ne caractérise pas le nombre des changements, mais la version de l'API de base. Tout le monde ne respecte pas cette convention, mais elle est assez répandue.
Je ne suis pas sur de bien comprendre ce que tu veux dire.
Si après le parsing XML tu te retrouves avec des arguments du genre "M-119 -21 L-120 -14 A180 20 180 1 0 120 -14 L119 -21", il faut bien les parser aussi, c'est à dire écrire un micro-parseur, exactement comme le monsieur a dit.
Evidemment ça n'est plus un problème XML, sinon il n'y aura pas de parseur à écrire :-).
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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 Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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) . En réponse à la dépêche Al Stevens n'aime pas QT. É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 Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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: pfieww super grave
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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: Les gouts et les couleurs...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. Évalué à 1.
Y a Q_PROPERTY aussi, moins connu mais quelques fois très utile.
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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: Il a tort.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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: Comment ça marche ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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: Pareil
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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 Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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: Bof...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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).
# Il a tort.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. É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: Petites réponses :
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche le site de Ximian fait peau neuve. Évalué à 2.
Linus voulait bien l'appeler "Freax", mais je n'ai jamais vu nulle part que le nom "Linux" vienne de Torvalds lui-même.
[^] # Re: La course au numéros
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE 3.0. Évalué à 1.
Non.
> Logiquement, dans le boulot de KDE, le but est un peu de faire en sorte que le programmeur qui fait du KDE n'a pas à prendre en compte des considérations de bas niveau (niveau Qt).
Non plus. Qt n'est pas si "bas niveau" que ça.
> Là c'est comme imposer un changement dans le langage C sous prétexte qu'on va faire tourner le programme sur un nouveau processeur.
Non, rien à voir. Qt n'est pas un langage.
> Je ne vois vraiment pas en quoi le passage à Qt3 impose un changement d'API sur KDE, le prochain KDE pourrait tout simplement être capable de se servir de Qt3, son API à lui restant compatible.
Ça voudrait dire wrapper toutes les classes Qt. C'est techniquement possible, mais parfaitement inutile, et le résultat serait mauvais.
Par exemple, dans Qt2 on avait QArray et QVector, maintenant dans Qt3 on a QValueVector et QPtrVector, et leur APIs ont légèrement changé (en mieux). Ces classes sont couramment utilisées dans les libs et les applis KDE. Selon toi, il aura fallu creer KArray et KVector dès le début de KDE pour assurer la compatibilité ? C'est un casse-tête sans nom, et complètement inefficace (tu ne peux plus profiter des améliorations de l'API).
> Alors, qu'est-ce que je n'ai pas compris ?
Comment est construit KDE.
[^] # Re: Enlightenment ...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE 3.0. Évalué à 1.
[^] # Re: [OT] I'm scared.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche ESR: How To Ask Questions The Smart Way. Évalué à 1.
http://tuxedo.org/~esr/guns/(...)
[^] # Re: OpenGL
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE 3.0. Évalué à 1.
Y a bien des screensavers avec de la jolie 3d qui utilisent OpenGL, mais le fond d'écran ce sont des images, ou des gradients générés à la volée.
[^] # Re: Pas uniquement le vocabulaire, le fond aussi !
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche ESR: How To Ask Questions The Smart Way. Évalué à 0.
[^] # Re: Enlightenment ...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE 3.0. Évalué à 2.
On sait jamais, ça peut interesser. :-)
[^] # Re: Question de vocabulaire...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche ESR: How To Ask Questions The Smart Way. Évalué à 4.
Enfin, je ne sais pas si c'est de l'ultra-libéralisme, plutôt de l'élitisme revendiqué. Mais bon, il faut bien qu'il y en ait encore pour croire et continuer de faire croire que l'Open Source est plein de programmeurs surdoués.
Il y en a, c'est vrai, mais c'est pas la majorité :-).
[^] # Re: La course au numéros
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE 3.0. Évalué à 6.
C'est le cas. :-)
> En fait, il semble que le passage à 3.x soit fait pour suivre Qt.
Voilà. Qt passe à la version 3 parce que la nouvelle API est incompatible avec la version 2. Il va donc en être de même avec l'API de KDE puisqu'elle est basée sur Qt.
L'incrémentation du numéro de version majeur ne caractérise pas le nombre des changements, mais la version de l'API de base. Tout le monde ne respecte pas cette convention, mais elle est assez répandue.
[^] # Re: Papa c'est quoi ce format de fichier ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le SVG enfin validé. Évalué à 1.
Si après le parsing XML tu te retrouves avec des arguments du genre "M-119 -21 L-120 -14 A180 20 180 1 0 120 -14 L119 -21", il faut bien les parser aussi, c'est à dire écrire un micro-parseur, exactement comme le monsieur a dit.
Evidemment ça n'est plus un problème XML, sinon il n'y aura pas de parseur à écrire :-).
[^] # Re: Papa c'est quoi ce format de fichier ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le SVG enfin validé. Évalué à 2.
Et comment fait-elle pour comprendre les paramêtres sans les parser ? :-)