Dans une optique commerciale, oui, mais tu conviendras que tu t'en fous un peu lors d'un développement de type hobby.
Globalement non, bien sur, mais quand même un peu. Quand tu obtiens un résultat acceptable en 2 jours de dev, t'as pas forcément envie de passer 10 jours de plus pour un gain hypothétique. Il faut bien se dire qu'optimiser un truc, c'est un boulot sans nom. D'abord, tu ne sais quasiment jamais où tu perds le plus en perfs. N'importe quel developpeur un peu expérimenté te dira que les parties lentes de ton code ne sont jamais celles auxquelles tu t'attends. Il faut profiler ton soft pour être sur de là où tu dois chercher à améliorer les perfs.
Ensuite, dans l'optimisation tu vas obligatoirement casser quelque chose. Statistiquement, tu es presque sur d'introduire des bugs. Et si par "optimisation" tu veux dire "ré-écrire avec un langage plus rapide", là c'est pire.
Mais pour ce qui est de GTK, tu es bien placé pour le savoir, ça reste objet, léger et simple d'utilisation.
Au contraire, je suis bien placé pour savoir que c'est à l'objet ce que la mobylette est à la voiture, très lourd, et pas simple du tout à utiliser. Mais dès que tu fais de l'objet sans que ce soit supporté au niveau du langage (ie avec un langage pas objet, C ou un autre), tu vas arriver à ça. Ceci dit oui, GTK+ reste plus sympa à utiliser que Motif, mais globablement ça reste un truc assez horrible. Tu passes ton temps à faire le boulot du compilateur avec des casts à tout va et la dérivation à la main.
Le côté boite noire fait que tu n'as pas vraiment à savoir ce que fait l'objet en interne mais pour l'utiliser correctement, tu dois connaitre quand même son fonctionnement interne.
Si c'est le cas, c'est que l'objet a été mal designé. Malheureusement en pratique c'est souvent vrai, mais on progresse. Il a fallu du temps pour qu'on comprenne bien comment faire de l'objet. Sur la question, je te conseille le chapitre d'intro du fameux "Design Patterns".
alors qu'on peut faire mieux sans cet amas de couches.
Oui, mais là encore au prix d'un temps de développement accru. Et encore, ça n'est pas évident que tu va gagner en perfs. Pour reprendre l'exemple de l'OO en C vs. un langage objet comme C++ : un compilo C qui voit un appel à une fonction à travers une table (pour émuler une méthode virtuelle) traduit ça tel quel, parce qu'il ne sait pas ce que c'est. Un compilo C++ sait ce qu'est une méthode virtuelle et peut le traduire de manière bien plus efficace.
C'est un peu comme si tu dictes une ordonnance médicale à quelqu'un qui n'y connait rien : il va noter scrupuleusement chaque mot, parce qu'il ne comprend pas de quoi ça parle. Si tu la donnes à un pharmacien, il va comprendre de quoi il s'agit, et par exemple pouvoir te dire que tel médicament est équivalent à tel autre qui coute moins cher, ou que ces deux médicaments là peuvent être remplacé par un seul, etc...
Un autre exemple c'est que tu peux facilement exprimer des choses plus efficaces. Par exemple, les classes de listes ou de string etc... de Qt (QList, QString, QArray...) sont bien plus efficaces qu'un équivalent en C parce qu'elle savent gerer leur données internes avec des compteurs de references, faire du Copy On Write, etc... Donc un truc du genre :
QString a = "blah"; // a copie "blah"
QString b = a; // b reference le char* interne de a
// donc pas de copie
b[0] = "c"; // b cree automatiquement sa propre copie de "blah" et la modifie
C'est impossible d'avoir ce niveau de controle en C, ça serait infernal à coder et à debugger. Donc un QString est plus gros qu'un simple char* (pas de beaucoup, quelques octets de plus), mais son utilisation est en moyenne beaucoup plus efficace.
Augmenter les couches d'abstraction coute un peu en perfs, mais t'en fait gagner beaucoup aussi. Il faut juste le temps que les compilos s'améliorent.
ce que tu gagnes en temps de developpement, tu le fais perdre largement en infrastructures
Mais le temps de développement coute en général plus cher que les infrastructures. En plus il y a l'utilisation ensuite.
Si tu fais un serveur en Java au lieu de C++, tu vas le finir 3 fois plus vite (c'est le gain généralement constaté je crois) et le résultat sera plus fiable qu'en C++ (Java a sa part d'emmerdes, mais globalement c'est ça). Si ton serveur fait un boulot un tant soit peu crucial et donc que chaque fois qu'il tombe ça se traduit par une perte d'argent (les gens peuvent plus bosser, les clients peuvent plus contacter le site web, etc...), le coup des machines est très vite amorti.
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 3.
Globalement non, bien sur, mais quand même un peu. Quand tu obtiens un résultat acceptable en 2 jours de dev, t'as pas forcément envie de passer 10 jours de plus pour un gain hypothétique. Il faut bien se dire qu'optimiser un truc, c'est un boulot sans nom. D'abord, tu ne sais quasiment jamais où tu perds le plus en perfs. N'importe quel developpeur un peu expérimenté te dira que les parties lentes de ton code ne sont jamais celles auxquelles tu t'attends. Il faut profiler ton soft pour être sur de là où tu dois chercher à améliorer les perfs.
Ensuite, dans l'optimisation tu vas obligatoirement casser quelque chose. Statistiquement, tu es presque sur d'introduire des bugs. Et si par "optimisation" tu veux dire "ré-écrire avec un langage plus rapide", là c'est pire.
Mais pour ce qui est de GTK, tu es bien placé pour le savoir, ça reste objet, léger et simple d'utilisation.
Au contraire, je suis bien placé pour savoir que c'est à l'objet ce que la mobylette est à la voiture, très lourd, et pas simple du tout à utiliser. Mais dès que tu fais de l'objet sans que ce soit supporté au niveau du langage (ie avec un langage pas objet, C ou un autre), tu vas arriver à ça. Ceci dit oui, GTK+ reste plus sympa à utiliser que Motif, mais globablement ça reste un truc assez horrible. Tu passes ton temps à faire le boulot du compilateur avec des casts à tout va et la dérivation à la main.
Le côté boite noire fait que tu n'as pas vraiment à savoir ce que fait l'objet en interne mais pour l'utiliser correctement, tu dois connaitre quand même son fonctionnement interne.
Si c'est le cas, c'est que l'objet a été mal designé. Malheureusement en pratique c'est souvent vrai, mais on progresse. Il a fallu du temps pour qu'on comprenne bien comment faire de l'objet. Sur la question, je te conseille le chapitre d'intro du fameux "Design Patterns".
alors qu'on peut faire mieux sans cet amas de couches.
Oui, mais là encore au prix d'un temps de développement accru. Et encore, ça n'est pas évident que tu va gagner en perfs. Pour reprendre l'exemple de l'OO en C vs. un langage objet comme C++ : un compilo C qui voit un appel à une fonction à travers une table (pour émuler une méthode virtuelle) traduit ça tel quel, parce qu'il ne sait pas ce que c'est. Un compilo C++ sait ce qu'est une méthode virtuelle et peut le traduire de manière bien plus efficace.
C'est un peu comme si tu dictes une ordonnance médicale à quelqu'un qui n'y connait rien : il va noter scrupuleusement chaque mot, parce qu'il ne comprend pas de quoi ça parle. Si tu la donnes à un pharmacien, il va comprendre de quoi il s'agit, et par exemple pouvoir te dire que tel médicament est équivalent à tel autre qui coute moins cher, ou que ces deux médicaments là peuvent être remplacé par un seul, etc...
Un autre exemple c'est que tu peux facilement exprimer des choses plus efficaces. Par exemple, les classes de listes ou de string etc... de Qt (QList, QString, QArray...) sont bien plus efficaces qu'un équivalent en C parce qu'elle savent gerer leur données internes avec des compteurs de references, faire du Copy On Write, etc... Donc un truc du genre :
QString a = "blah"; // a copie "blah"
QString b = a; // b reference le char* interne de a
// donc pas de copie
b[0] = "c"; // b cree automatiquement sa propre copie de "blah" et la modifie
C'est impossible d'avoir ce niveau de controle en C, ça serait infernal à coder et à debugger. Donc un QString est plus gros qu'un simple char* (pas de beaucoup, quelques octets de plus), mais son utilisation est en moyenne beaucoup plus efficace.
Augmenter les couches d'abstraction coute un peu en perfs, mais t'en fait gagner beaucoup aussi. Il faut juste le temps que les compilos s'améliorent.
ce que tu gagnes en temps de developpement, tu le fais perdre largement en infrastructures
Mais le temps de développement coute en général plus cher que les infrastructures. En plus il y a l'utilisation ensuite.
Si tu fais un serveur en Java au lieu de C++, tu vas le finir 3 fois plus vite (c'est le gain généralement constaté je crois) et le résultat sera plus fiable qu'en C++ (Java a sa part d'emmerdes, mais globalement c'est ça). Si ton serveur fait un boulot un tant soit peu crucial et donc que chaque fois qu'il tombe ça se traduit par une perte d'argent (les gens peuvent plus bosser, les clients peuvent plus contacter le site web, etc...), le coup des machines est très vite amorti.