après compîle, j'ai 3 fatal error :

fatal error C1010: unexpected end of file while looking for precompiled header directive
 
fatal error C1010: unexpected end of file while looking for precompiled header directive
 
fatal error C1010: unexpected end of file while looking for precompiled header directive

 
enfin... ce sont les trois mêmes erreurs... que je n'arrive pas à résoudre.
 
ces sources (où le compilateur me met des erreurs) m'ont été fournis est marchent parfaitement... avec d'autre programmes !
 

Il doit te manquer une parenthèse, ou un #endif, enfin un truc comme ça, mais sans le code je ne sais pas dire plus ...

le code est assez conséquent, je ne px pas me permettre de le mettre sur ce forum.
La seule chose que je peux affirmer, c'est que ces sources fonctionnes parfaitement (passent à la compile), lorsqu'il sont employers dans un autre source.
Je me demande plutot si ca ne viendrai pas d'un paramètre que j'ai oublié de validé pour la compile...
Mais les erreurs que le compilo me trouve dans les sources n'ont pas lieu d'être...

 
c'est un problème du visual C. Il utilise normalement des "precompiled headers" afin de gagner en performance au niveau du préprocesseur. On peut aussi le faire avec les dernières version de gcc mais c'est mieux fait. Bref, dans les options du projet, il faut donc lui dire de ne pas utiliser ce mode et c'est réglé.

Autant pour moi ... utilise générer automatiquement dans les options

 
ou faire  
#include "stdafx.h"  
 
en premiere ligne dans les includes du .c/.cpp a compiler
ce qui me parait plus intelligent

 
Je ne pense pas, non. Mais bon, il peut le faire comme cela si ça lui chante. Mais il faut alors qu'il crée un stdafx.cpp, qu'il l'inclue dans son projet et qu'il le configure pour générer les precompiled à partir de ce fichier. Après, il va falloir qu'il édite chacun de ses sources pour ajouter l'include.
 
Si vous trouvez ça plus simple que de changer une option à trois sous, on n'a alors pas la même conception du simple.

 
Y'a plusieurs solution :
-Soit il a crée son projet dans PCH et la visual le ferait pas chier
-Soit il a crée son projet avec PCH et a rajouté ensuite ses fichiers sans le 'include "stdafx.h" ' et donc ca foire. Dans ce deuxieme cas, tout ce qu'il a a faire c'est de rajouter ledit include. (vu que VC a crée le reste pour lui). Le gain apporté par les PCH est suffisament important pour que l'on puisse prendre la peine d'apprendre a s'en servir.
 
 
 

 
Vous etes le seul a avoir lu "simple" dans mon precedent post. Puis je vous conseiller un opticien ?

 
He bien le gain apporté par les bugs liés au pch du visual jusqu'en version 6 est tellement grand que j'ai appris à les virer systématiquement dans mes projets
 

 
Je n'ai pas lu ça dans votre message. Mais je note que vous êtes susceptible.

 
j'ai jamais eu de pépin avec les PCH du 6 ? Enfin j'ai surtout commencer a utiliser ca intensivement dans le 2002 et j'ai jamais eu de soucis majeur de ce coté la. Parfois des erreurs de compilations inexplicable qui se resolvait avec un rebuild all, mais c'est franchement plus l'exception que la regle.  

 
Les erreurs de compilation inexplicables sont dûes à des bugs dans la gestion des dépendances. En clair, il arrive que le changement d'un header inclu dans le pch ne déclenche pas la recompilation de celui-ci ansi que de tous les fichiers liés. Ce n'est généralement pas trop grave tant qu'on ne fait qu'ajouter des fonctions à une classe (par exemple) parce que si vous utilisez la fonction ailleurs dans votre code, le compilo vous crachera une erreur à la figure comme quoi la méthode n'existe pas pour lui. Mais si à la place d'ajouter une méthode, vous changez le code d'une fonction inline, l'histoire ne sera pas du tout la même. Il y a d'autres petits détails bien chiants mais bon, après, c'est plus une histoire de goût.

 
 
vivi, d'ou le rebuild all

 
Ca aussi, c'est le truc que j'adore dans les projets utilisant des pch bien trop souvent mal faits. Pour se faire une dll, le mec fait un bon gros header avec tous ses includes dedans (ben oui, c'est "vachement" over tip top pratique) et à chaque fois qu'on change un poil de cul quelque part, c'est parti pour la recompilation du projet en entier. Il y en a qui perdent des heures à regarder leur machine faire des compilations comme ça...

 
et pourtant il suffit de lire le code généré
 

 
(fodrait ptet lui dire un jour de la debugger un brin, la coloration)

 
Mouais. C'est sûr que si le mec ne colle que des afxproutprout dedans, ça peut encore être acceptable. Le reste du temps, il vaut mieux s'en passer parce qu'on fait ça comme un sagouin et qu'on a alors droit à des erreurs "inexplicables" et des rebuild all à tire-larigot.

 
non, je suis pas d'accord, si tu suis les regles etablies dans le bout de commentaire quoté, tu n'auras que tres peu de pb, et tu sacage tes temps de compilation.

 
Mouais... je ne suis même pas sûr qu'on y gagne quand on a peu de fichiers à recompiler (avec des dépendences bien foutues) comme c'est souvent le cas quand on est en cours de dev. Parce qu'il faut bien dire que la taille du pch grimpe vite à plus de 10 méga-patates. Mais bon, à mon sens, c'est plus une affaire de goût qu'autre chose tout ça.

les 10megapatate, on s'en fout

 
Ben oui, puisque je ne suis pas encore assez sénile pour utiliser les precompiled proutprout de krosoft. Ah oui, au fait, un bon compilateur C/C++ pour windows, c'est CodeWarrior.

 
Merci de ton intervention

 
Tiens, je suis sûr que vous ne savez que l'assembleur généré par le visual est à chier. Mais bon, c'est normal. Vous êtes jeune...

 
quelle version de visual ? quel cas ?
Savez vous qu'il existe un mode "release" ?

 
Ah ben non, c'est quoi donc ça, "release", un god ceinture?

 
bon plus serieusement, t'as du cas a montrer de code a chier ?

 
Encore plus simple, allez-donc voir le memcpy en débuggant une release. Le summum de l'inefficience...

VC 6 n'est pas top ... .NET est mieux tout de même, perso je trouve le compilo Intel bien

mauvais exemple, memcpy est ecrite en asm, ca n'a donc rien a voir avec le compilo

 
Si justement. C'est de 'bon' augure pour la suite.

 
heuh...
non.

 
Ahhh ces jeunes, ils ne comprennent rien à rien...

 
la génération de code me semble etre autre chose que du code asm ecrit a la main.

 
Et qu'est-ce qui est le plus facile à optimiser, le code écrit à la main ou le code généré?

 
c'est un peu pas la meme chose quand meme

 
Taratata jeune homme. On répond à la question.

 
code ecrit a la main.
 
maintenant reponds a la mienne : ecrire de l'asm a la main est il comparable a ecrire un generateur de code ? comment ecrirait tu la memcpy ?

 
Sur certains points, oui. Sur d'autres non.
 

 
Il faut détecter en début de programme le processeur sur lequel le bousin tourne.
Ensuite il faut initialiser un pointeur sur fonction avec le memcpy le plus performant selon le processeur
C'est-à-dire utilisant les jeux d'instructions qui n'ont pas été faits pour les chiens (SSE, MMX, 3DNow & cie)
Ensuite, on vire du memcpy leur test à la noix sur les zones mémoire overlapped. D'une, ce n'est absolument pas portable et de deux, à part si on bosse pour krosoft, il est rare qu'un programmeur fasse ce genre de copies. En clair, ce test ne fait au mieux que gâcher des cycles et, au pire, que pourrir la portabilité.
 
Sur ce, bon week-end.