On Friday 14 June 2002 10:42, Marc SCHAEFER wrote: > - gcc est un compilateur C, et les binutils (ld.so, etc) sont > des outils d�velopp�s pour le C. Le C++ a des demandes bien > diff�rentes concernant les performances des linkers. Notamment > p.ex. l'ordre de grandeur de gros programmes en C pour le nombre > de symboles *export�s* est 10^3. En C++, c'est plut�t 10^6. > KDE a cach� ce probl�me dans sa version 2 gr�ce aux processeur > `kdeinit' qui pr�chargent les symboles; et r�solu dans la version 3 > gr�ce � des tables pr�-calcul�es.
Surtout C++ a une contrainte importante li�e � l'initialisation des constantes des classes... Cela ne peut pas �tre effectuer par les "initialiseurs" (option -i du linker) des shared libraries (du moins les compilateurs C++ ne font aucun effort d'optimisation dans ce sens). Ce qui fait que le programme de l'utilisateur effectue ce genre de travail � partir de code g�n�r� par le compilateur (c'est assez lourdingue). Aussi, un grand nombre de d�veloppeurs sont de grands flemmards qui pr�f�rent utiliser l'option --export-dynamic de ld plut�t que de faire le m�nage dans leur code. Il est nettement pr�f�rable d'exporter une liste exhaustive de symboles au lieu de *tous* par d�faut. De plus, faire du C++ en exportant des variables globales est une insulte � la notion d'encapsulation d'un code OO. Seuls les symboles "code" (adresses des fonctions) devraient �tre export�s ! Or, en C++ chaque m�thode "public" d'une classe est une focntion (adresse) export�e. Vous comprenez maintenant pourquoi C++ est plus gros et plus lent; rajoutez � cela des "virtual fonction" et vous atteignez des sommets... :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
