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
