Reprise du message précédent :
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!

Oups, en effet
Je n'avais pas vu.
 
Mais en désassemblant je trouve crtdll.dll, et pas msvcrt.dll
 
Bizarre, vu que crtdll.dll date de 1994... c'est une ancienne version de msvcrt.dll (que j'ai sur le disque)

+1
Apparemment, seul le temps de compilation le pénalise, mais ça honnètement, je m'en tape un peu !

franchement on s'en fou un peu du temps d'execution d'un programme en C++ suivant les compilos
 
on est pas en java ou en vb, le C++ c'est rapide, et si ca jouait y'a 10 ans, maintenant on s'en fou un peu
pareil pour la taille des exe, que ca fasse 500ko de plus avec bidule qu'avec machin, bof
 
y'a tellement de criteres bien plus important desormais que la rapidite du code genere (evidemment si en plus le compilo est rapide je crache pas dessus)
 
eliminer par exemple Borland parceque les temps d'execution sont pas fabuleux, je trouve ca ridicule
 
si votre programme est lent, hop un coup de profiler et on change l'algo qui fait ramer le bousin suivant le principe : 10% du code prend 90% du temps cpu
 
ceci dit le test a l'air vraiment bien fait et tres serieux, c'est toujours interessant a lire

 
Quand tu fait de la simulation numerique, ca deviens important la vitesse d'execution...

Pour le classement de gcc, je faisais reference a la qualite du code genere.
Sinon ils disent que VC++ est bugge mais bon moi j'ai pas eu de pblm avec, sauf peut etre une mauvaise surprise avec ce unsigned/signed char.
 

 
 
Hum ... ca reste a voir. Comme tu dis, on crache pas sur une amelioration sans rien avoir a faire des perf.
 

 
 
Non, le code genere est assez mauvais (uniquement la version Windows).
 
C'etait surtout a titre indicatif, histoire de relativiser les choses.
On entend tellement gueuler sur tel ou tel produit uniquement parce que gnagnagna Microsoft ... (fin du debat )

 
Quand tu te retrouve avec une internal compiler error du rales quand meme un peu !
 
bon c'est vrai que j'abuse des templates, mais bon...

Sous Windows, j'en ai eu bcp plus avec gcc que vc++

Je ne fait pas partie du "on".
Je pense qu'une solution lente/encombrante n'est pas une bonne solution.
Je pense que le morceau de code anodin peut servir dans des situations critiques non prévues, et que ça fait pas de mal de bien le concevoir.
 
Pour ces raisons, j'aime le C++ qui permet de mieux structurer, et d'affiner les performances.

c'est sur que formule comme ca tout le monde est d'accord avec toi
mais la on ne parle pas de solution lente/encombrante, on parle de compilos C++
 

on s'en fou des cas particuliers, on parle de maniere general, c'est a dire de 90% des softs qui sont programmes en C++ et qui sont disponibles sur le marche
 
 
je vais reprendre ma phrase parceque tout le monde enterprete mal
je ne defend pas les compilos lents, je defends l'idee qu'entre un compilo X et un compilo Y il y a de forte chance qu'a l'oeil nu on ne voit pas la difference du temps d'execution et donc qu'aujourd'hui il y a des criteres plus importants que la qualite du code genere
surtout avec les becannes qu'on a actuellement

chui pas sur, rien qu'en augmentant le niveau d'optimisation (genre de O2 à O3), on voit déjà la différence. alors la performance du compilo est importante meme pour des petits programmes.
 
c'est pas parcequ'un exécutable est petit qu'il ne fait pas un gros traitement

 
je parle pas d'optimisation 03 ou 02, mais de la difference entre un borland, un gcc et un visual dans les memes conditions d'optimisation (bon evidemment icc est un peu a part)
 
par exemple quand j'utilise un soft en java, je le vois tout de suite que c'est du java ! et pas simplement a la gueule du toolkit
 
autre exemple, sous linux, t'as la distrib gentoo qui est entierement recompile avec toutes les optimisations possibles sous gcc
ba y'a pas mal de personne qui ont essaye et qui voit pas trop de difference avec par exemple une debian compile pour 386
et dans ce cas on parle de la distrib entiere recompile avec les optimisations (donc toutes les librairies de bases qui sont utilises par tout les softs), pas juste d'un soft !
 
en faite c'est plutot le temps de chargement du soft et son occupation memoire qui sont penalisants, une fois que le soft est lance c'est plutot lui qui attend apres l'utilisateur

Dans tous les softs sur-lesquels j'ai bossé la viyesse d'execution était capitale...
 
C'est vrai qu'il y avait bcp de simulation numerique...
 
Mais meme sans que ce soit capital, il toujours agreable d'avoir une application qui reponde rapidement, et savoir que tel compilo genere un code plus efficace qu'un autres est toujours bon a prendre...

 
j'ai dit "rien que" pour signifier qu'une simple optimisation supplémentaire a des répercusions énormes sur les performances, alors c'est clair qu'entre 2 compilateurs, la différence peut etre énorme.
 
c'est clair que si on fait un programme à la con genre "hello world!" on s'en fout mais si on fait un truc qui mouline un peu, ca change tout. J'avais fait un traitement de BMP: sur un fichier test de 2Mo sur un 733Mhz, 45secondes sous windows avec bcc, 30secondes avec gcc sous linux(et meme 23sec en -O3). ca c'est de la difference!

j'ai pas dit que je m'en foutait !
dans le choix d'un compilo C++ il y a pleins de criteres dont la vitesse du code genere, mais pour moi ce critere c'est clairement pas le principale
 
genre, un compilo qui est 5% plus rapide que les autres mais qui n'aime pas les templates, supporte pas 2 boucles for d'affiles, se trimbale avec une STL de merde, des bugs de partout, un niveau de warning lamentable et des libs merdiques (mais non personne ne voit de quel compilo je parle...)
ba je prefere de tres loin un compilo qui respecte la norme un minimum, qui a un niveau de warning acceptable, et qui me permet d'apprecier toute la puissance du C++ et sa portabilite meme s'il est 5% moins rapide
 
y'a pas que la vitesse d'un compilo qui est important, moi j'ai envie de programmer en C++, pas en une extension du C avec juste des classes

 
 gcc/g++ POWA  

Taz@PPC a écrit a écrit :    gcc/g++ POWA

+1

J'ai reconnu le coupable d'après le portrait-robot, et je l'ai sous la main.
Je l'amène au poste de police ? Ou je le jette ?
 
Le jour où je distribue un programme, je l'aurais soigneusement conçu et compilé.
Par respect pour les utilisateurs...

Avec ta grande sagesse peux tu me dire pk mon prog prends 140Ko sous Win2000 pro et seulement 40Ko avec le meme compilo,les memes nivo de warning(a savoir dev-c++)??

Pas d'idée bien nette...
 
Une possibilité, c'est qu'il incorpore des fonctions de conversion vers les chaînes unicode attendues par Windows 2000.
Mais Windows 2000 reconnaît les appels ANSI (compatibilité W9x).
Et puis +100 Ko... c'est beaucoup.
 
Peut-être le fait de se lier au deux versions: Unicode et ANSI ?