Re: HS: C++

[Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net>]

Thu, 4 Nov 2004 11:32:14 +0100, Gabriel Paubert a écrit :
>[...]
> 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.

Ouh là, on est tombé sur un « vieux de la vieille » ! ;o)

Et bien oui, c'est aussi ce que j'entendais par « maîtriser le C++ » : le
fait de connaître les résultats de la compilation est parfois
indispensable. Et on ne peut pas toujours deviner ce résultats grâce à
l'expérience que l'on aurait dans d'autres langages (tu en es la preuve
vivante).

> 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 aussi parce que le C++ contient quand même pas mal de bidouilles
(notamment les templates). Le fait que le C++ offre différentes
possibilités, c'est bien. Mais le problème, c'est que les avantages et les
inconvénients de chacune ne sont pas clairement définis (c'est plutôt
présenté comme une histoire de goût). Le pire, c'est que ces
avantages/inconvénients résultent de choix faits à différents niveaux :
- le standard du langage ;
- la mise en œuvre dans les bibliothèques ;
- les compilateurs.

Exemple simple : si i est un itérateur de la STL, il vaut mieux faire
++i que i++. Comment le sait-on ? Il faut regarder le code...
(Alors que ces deux alternatives sont présentées comme équivalentes,
notamment dans un for(; ; ++i). )

> 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.

C'est un peu triste mais je suis d'accord. C'est d'ailleurs une chance que
je me sois éloigné du C++ juste un peu après l'apparition de la libqt
(vers 1996). Ce qui est dommage, c'est qu'à l'époque, j'avais un peu les
mêmes réflexions que toi sur le différents toolkits (peu nombreux encore),
à part qt qui proposait une solution intéressante avec les signaux. Depuis
lors, je n'utilise le C++ que pour les parties nécessitant des appels
système ou qui ne servent qu'au calcul. Les GUI en C++, j'évite. J'ai de
la chance, j'ai rarement des impératifs de rapidité d'exécution (sur les
GUI en tout cas).

> 	Gabriel "small is beautiful"

Itou.
-- 
Sylvain Sauvage