Une question rapide : je viens d'installer MinGW car je dois porter un projet sous linux. MinGW me permettra de tester différentes modifs sous Win avant de les porter sous Linux. J'ai essayé de compiler le code tout con suivant :
 

 
Taille de l'éxécutable a.exe : 439 Ko !!!
 
Pour compiler, rien de plus simple :
g++ toto.cpp
 
C'est normal un éxécutable aussi gros ?

Attends, j'essaye chez moi et je te dis...

Hum... 130Ko chez moi.
Ca parait beaucoup quand même !

"L'équivalent" en C fait juste 10Ko compilé

Tu compiles comme moi ?    
Serait-ce parce que je suis sous NT 4.0 SP6 ?

Bein ouais:
J'ai fait : "g++ toto.cpp"
Il m'a bel et bien fait un exe de 130Ko.
Je ne peux pas te dire pourquoi cette difference de taille!
Sinon, J'utilise gcc 2.95.3-6 (special)

Harkonnen a écrit a écrit :   Tu compiles comme moi ?     Serait-ce parce que je suis sous NT 4.0 SP6 ?

Avez vous supprimez les options de debugger infos?Ca bouffe beaucoup ces petites choses la!

Ma version de MinGW (2.0) semble comporter la version 3.2 de GCC, peut être que ça vient de la... je teste

On fait comment ?  

moi je le sens venir de la ton probleme pourtant normalement tu compiles pas en debug (pas de -g)
 
sinon autre solution, tu specifies -lstdc++ a la compilation ca diminuera la taille de l'exe
 
http://lists.kde.org/?l=kde-core-d [...] 006814&w=2
 
Debug binaries don't grow as much as with the CVS version I tested, but still  
they get twice as big with 3.1 (with the CVS version, it was a factor of 3):
 
debugging version of qt compiled with 2.95.3:
-rwxr-xr-x    1 root     root          28M May 17 11:27 libqt-mt.so.3.0.4
 
and with 3.1:
-rwxr-xr-x    1 root     root          54M May 17 01:05 libqt-mt.so.3.0.4
 
Non-debug builds seem to be comparable in size though.

Gagné !
 
Taille de l'éxécutable avec gcc 2.95 : 46 Ko !
Avec gcc 3.2 : 439 Ko !!!
 
Ca fait quand même beaucoup, comment ça se fait ?    

Harkonnen a écrit a écrit :   On fait comment ?

 
Le probleme c que je sais pas sous dev-C++ t as une option a decocher mais sous gcc et g++ peut etre qu avec le --help tu trouveras comment desactiver ca!

Harkonnen a écrit a écrit : Gagné !   Taille de l'éxécutable avec gcc 2.95 : 46 Ko ! Avec gcc 3.2 : 439 Ko !!!   Ca fait quand même beaucoup, comment ça se fait ?

He 46Ko?
J'en ai 130Ko avec ma version  

ITM : en C compilé avec LCC je fais un exécutable de 3,03 ko
(Sans optimisation)

Essaye d'utiliser strip sur l'executable que tu obtiens.

A titre de comparaison, sous visual C++ 6 sp 5:
 52 Ko en release
221 Ko en debug
 
Au pif, je dirais que des librairies inutilisées sont incluses à tort.

c bien mon avis aussi, mais lesquelles ? et comment le savoir ?

voila la reponse a ton probleme :
 
> pour ceux qui pleure en voyant les tailles des exe générés par g++ meme en Os, il suffit de rajouter
> "-s -D__GTHREAD_HIDE_WIN32API"
> et on retombe sur des exe tout maigres...
> dans les prochaines versions, cette option sera par défaut
 
http://presencepc.com/sqlforum/for [...] h=&subcat=

Merci moi

Taz@PPC a écrit a écrit : Merci moi

 
clair
 
t'as trouve ca dans les archives de la mailing-list ?

nan j'ai posé une bug-feature sur sourceforge et les concepteurs m'ont répondu. y plus qu'a attendre...
 
c'est surtout le -s qui a une action significative sur la taille d'executable, l'option pour l'API de windows réduit le temps de compilation.
 
pour debugguer ou profiler, mieux vos compiler sans ses options

-s c'est pour faire un strip de l'executable. Je crois que ca fait la même chose que de faire strip xxxx.exe après l'avoir compilé. Par contre faut pas esperer deboguer la chose après un traitement pareil.

exactement

Effectivement, la taille baisse de manière considérable avec ces options, cependant, tout ça ne nous dit pas :
 
- Pourquoi une telle différence de taille entre la version 2.95 et 3.2 ?
- Pourquoi une telle différence de taille entre g++ et lcc ?

par ce que dans la 2.95 les  options "-s -D__GTHREAD_HIDE_WIN32API" etait par défaut.
 
quand a lcc, tout depend. si tu compile en -O3 ou -Os onva bien voir
 
pi lcc il fait que du C

Ouai, dans le doute j'ai fermé ma gueule, mais 3 Ko avec un printf dedans, ca me semble louche ...
Soit la lib standard de LCC est miraculeuse, soit y'a une bonne grosse dll qui traine quelque part ...

Et pourtant on peut en faire des choses en 3103 octets d'instructions.
 
Il me semble que certains compilateurs sont capables de ne pas inclure le code des formats de printf pas utilisés.
Ou alors il a mis un simple puts.

 
Comme se lier a crtdll.dll qui fait 145 Ko ...
Ils ont ete malin, ils utilisent la dll de Microsoft qui est installee avec Windows ...
 

 
puts ou printf, il faut initialiser la console (recuperer les handle standards) et si c'est correctement programmé, ca prend deja quelques lignes ca.
Je ne parle pas de l'initialisation du tas etc ... pour des appels eventuels a malloc et consors.
Qui plus est, y'a le int argc, char ** argv à formater.
Ca aussi ca prend pas mal de lignes.
Enfin, le  code de printf (le vrai, pas la version allégée qu'offre Windows) est assez imposant.

c'est vrai que printf n'est pas une petite fonction (c'est d'ailleurs pour ca qu'elle a été abandonné en C++ qui offre de E/S plus rapides)
 
outre cette histoire de dll, la perfromance d'un compilateur ne se voit pas en compilant un "Hello World!"
 
Certains compilos crachent directement plusieurs dizaines deko mais apres la taille augmente tout doucement.
 
la prochaine génération de compilateur/lieur devrait etre capable de supprimer le code inutile à la liaison. (certains le font déjà partiellement et sous certaines conditions)
 
sinon, y a "upx --best" et zou...

Le fait de sortir le code de printf dans une dll n'influe pas sur les performances.
 
Les dizaines de Ko sont generalements provoque par un link statique de cette dll ainsi que le code necessaire aux exceptions, etc ...
 
Quant aux linker, je crois qu'il s'agit des "smart linker" et que celui de Borland en est un.
 
Pour upx, c'est un autre debat ... qui s'est souvent terminé par "compresser un exe c'est mal" (l'OS ne peut plus effectuer la pagination sur le code)

 
chai po il me semble que c'est décompressé et pas exécuter comme ça. de toutes façons, ce n'est pas une solution si ton exe est énorme et fait de tres gros traitements

 
 
C'est le travail du système compilation/liaison d'inclure ce qui est nécessaire, et pas ce qui ne l'est pas.
Quand un simple "Hello world" qui n'utilise pas les variables d'environnement, ni le tas, ni les exceptions, ni le formatage, se trimbale quand même des wagons de code, inclus des messages d'erreur pour des fonctions inutilisées, des noms du source qui n'ont rien à y faire, et de vastes zones tampons...
Alors je peut pas m'empêcher de penser que si le travail est mal fait à ce stade, il l'est tout autant pour le reste.
 
Cela dit, je suis tout à fait conscient que la taille des exécutables n'est pas un problème pour beaucoup de monde.
Le jour où ça en devient un, le réveil peut être dur.
 
ch'tite contribution: http://www.codeproject.com/tips/ag [...] print=true

cool ton lien (dommage que j'utilise pas VS   )

Non, LCC génère des exe vraiment indépendants
Pas besoin de DLL !
Vous pouvez essayer par vous même, LCC ne fait que 3.3 mo, (avec les libs et les includes bien entendu)
http://www.cs.virginia.edu/~lcc-win32/
 
En mettant ce code :
#include <stdio.h>
   
int main(void)
{
    printf("test\r\n" );
    return 0;
}
 
Et en compilant :
lc.exe prog.c
 
Ya pas d'entourloupe !
Ce compilateur n'est pas mon préféré pour rien :-)
(LCC est un compilo C, pas de C++)

Negatif ...
Je viens de tester.
L'exe utilise msvcrt.dll
Genere le fichier asm pour voir ...
Y'a 2 appels (j'ai meme dessassemble pour verifier) a cette dll :
un premier pour formater les arguments (argc, argv)
un second pour printf
 
On parle bien d'un exe de 3 Ko ... ?
Si ton exe pese plus et que tu t'es demerder a lier la dll en static, je veux bien te croire.
Mais je crois pas que la lib statique de cette dll (faite par MS) vienne avec le compilo (je peux pas verifier la desole)

Ce qui est vrai en revanche c'est qu'on est sur que cette dll est presente sur chaque ordi et donc pas besoin de la refourguer ... (sauf si la version change, ce qui a ete recement le cas je crois)

donc gcc reste bien le meilleur compilateur

Heu ... on parle de LCC ...
Je sais pas trop ce qu'i vaut en terme de code compile, mais je sais que gcc sous Windows est mal situe ...
 
http://casteyde.christian.free.fr/cpp/benchmarks/

Je vois pas pourquoi il serait mal situé sous windows d'après ce que tu postes. C'est même celui qui respecte le plus la norme!