[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HS: C++



On Thu, Nov 04, 2004 at 01:16:39AM +0100, Sylvain Sauvage wrote:
> Thu, 04 Nov 2004 00:31:24 +0100, Laurent Martelli a écrit :
> > >>>>> "Sylvain" == Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net>
> > >writes:
> > 
> >   Sylvain> Wed, 3 Nov 2004 20:26:16 +0100, Gabriel Paubert a écrit :
> >   >> [...]  Hériter d'une classe existante semble plus propre mais il
> >   >> faut vraiment en voir le coût, composer est nettement moins cher
> >   >> en terme de taille de l'exécutable et pas franchement pire dans
> >   >> ce cas.
> > 
> >   Sylvain> Le choix entre héritage et délégation n'est pas souvent une
> >   Sylvain> question de « propreté », c'est plus souvent une question
> >   Sylvain> de choix, surtout en C++.
> > 
> > C'est formidable ce que tu viens de dire, en résumant un peu ça
> > devient "le choix c'est une question de choix" ;-)
> 
> Oups, me suis eu tout seul. Remplaçons le second « choix » par « goût ».
> 
> > Ceci-dit, je pense que choisir entre héritage et délégation c'est un
> > question de propreté, mais ça ne veux pas dire qu'hériter est toujours
> > plus propre. Dans le cas qu inous intéresse (hériter de la classe
> > Window de gtkmm pour la fenêtre d'une appli), je pense qu'il est plus
> > propre de déléguer. L'héritage expose l'implémentation (l'utilisation
> > de gtk) alors qu'en ayant un attribut Window, tu peux le laisser privé
> > et donc encapsuler.
> 
> D'accord sur ce point. Mais la propreté, c'est parfois subjectif aussi.
> 
> >   >> C'était mon premier projet en C++, il se pourrait bien que ce
> >   >> soit le dernier.
> > 
> >   Sylvain> C'est le problème de C++ : il faut maîtriser la façon dont
> >   Sylvain> va être interprété le code pour programmer correctement. 
> > 
> > Je pense que c'est valable pour n'importe quel langage. 
> 
> Quand je dis maîtriser, je veux dire réellement maîtriser, pas seulement
> avoir une idée de ce qui se passe. On peut très bien programmer dans un
> langage comme Java, Python, Php, etc., sans se soucier de la façon dont
> sont stockées en mémoire les fonctions et les structures. En C++, on doit
> faire attention à de nombreux détails (notamment la gestion des fonctions
> virtuelles, ou simplement la gestion des structures en mémoire) si l'on ne
> veut pas avoir de mauvaise surprise.
> 
> Je ne dis pas que ce sont des complications inutiles du C++.
> Je dis simplement que le C++ nécessite beaucoup de connaissances pour être
> utilisable correctement (c'est-à-dire gagner quelque chose à l'utiliser).
> Je dis aussi que si on n'a pas besoin des avantages du C++, autant ne pas
> subir ses inconvénients (chacun pouvant percevoir avantages et
> inconvénients de son point de vue).
> 
> À mon avis, le C++ n'est pas un langage pour les débutants (je n'ai jamais
> vu de cours de C++ pour débutants qui traite vraiment le C++ et pas
> seulement un sous-ensemble restreint du C++).
> 
> Je ne dis pas non plus à Gabriel « bien fait pour toi si tu t'en as chié,
> le C++ ça se mérite, t'es qu'un noob, tu seras jamais l33t... ». Au
> contraire, ce serait plutôt « Persévère, il faut `juste' de l'expérience
> et tu en as déjà. »

Ben oui, mais de l'expérience dans d'autres languages, c'est pas ça qui
me manque. Je connais une vingtaine d'assembleurs (de 8 bits à 64 bits,
du 8051 au mainframe IBM en passant par le VAX, et quand je dis que je
les connais, ça veut dire au moins quelques milliers de lignes écrites 
dans chacun) et j'ai utilisé aussi une grande variété d'autres compilateurs 
et interpréteurs (Fortran, Pascal, Ada, C, PL/1, APL/APL2, Lisp, Python, et 
j'en oublie, mais ni Cobol ni Perl ne font partie la liste). Je suis juste 
un peu dégoûté par le fait que certains choix  en C++ ont une influence 
énorme sur la taille de l'exécutable, et que la plupart des programmeurs 
C++ s'en foutent (ceux de Gtkmm entre autres). En plus de l'explosion de 
la taille du code dues aussi aux génériques  (template), compréhensible 
dans certains cas, pas dans tous.

Cas particulier, libsigc++, je trouve la fonctionnalité géniale et je
suis prêt à payer un surcoût raisonnable pour la sécurité qu'elle
apporte mais le choix entre appel à la bibliothèque, instantiation d'un 
générique et code en ligne est fait en  dépit et même à l'encontre du 
bon sens. Un constructeur qui met juste une pointeur à NULL est dans 
la bibliothèque (rien que le nom de la fonction est plus long que le 
code machine!, et chaque appel est aussi bien plus long et plus lent 
que si le code était en ligne, surtout avec l'indirection de la PLT), 
mais une fonction d'une centaine d'instructions machine est toujours 
en ligne. J'ai limité les dégats en créant des fonction qui ont juste 
une instruction return, rien d'autre.

C'est le premier language dans lequel je n'ai aucune idée de ce que
va générer le compilateur, et ça me donne l'impression très désagráble 
de que je ne sais pas ce que je fais. Je pense sérieusement retomber 
sur C et Gtk, même si je n'aime pas Gtk, mais je n'ai pas non plus été
impressionné par wxwindows ni aucun autre toolkit (le seul qui m'a plu 
c'est Python+Tkinter, mais c'est vraiment trop lent pour ce projet).
Quant à libxclass, il n'est pas mûr et programmer directement avec 
Xlib ou Xt, non merci, même si ça doit être formateur.

	Gabriel "small is beautiful"



Reply to: