Bonjour,
 
Voici mon problème :
 
Je travaille actuellement sous Visual C++ .NET (je travaille en C++), et il s'avère que mon code a un comportement différent en ( Release ; Ctrl - F5 ) par rapport au reste.
 
Ma question :
 
Quelqu'un aurait-il une connaissance suffisamment approfondie de VC++ ou quelqu'un connaitrait-il un lien qui puisse m'expliquer sous forme simple (un ou deux tableaux) et complète, la différence entre les compilations Debug F5, Debug Ctrl - F5, Release F5 , Release Ctrl - F5 ?
 
Merci d'avance.
 
a.k.
 
---------------------------------------------------------------------------------------------
Résultat
 
F5

• Interception d'exceptions
• Gestion des breakpoints

Ctrl - F5
 
Debug

• Ajoute des 'informations' afin d'aider à debugger

Release

• Optimisation du code

---------------------------------------------------------------------------------------------
 
Je complèterais ce tableau plus tard, il pourra servir à qqn d'autre que moi    
 
(edit : section résultat)

quand tu fais Ctrl+F5, debug ou non, le debugger de Visual Studio ne prend pas la main sur le processus (pour intercepter les exception et placer les breakpoints prévus) alors qu'en mode F5 simple, si ...
 
pour le mode debug, il te rajoute des informations çà et là pour t'aider à debugger et compile sans optimisation par défaut.

 
rien de plus précis ?

ben, non, psa plus précis de mon côté ... Mais normalement, un prog qui passe en debug et qui ne passe pas en release, c'est typiquement un prog qui a un dépassement de capacité ou un pointeur qui part dans le vague ... Et ce sont les infos de debug rajoutée qui te sauvent la vie en mode debug

Le problème est que mon code passe en Release F5 et en Debug Ctrl F5 mais pas en Release Ctrl F5. Le pire est que le code compile et run sans problème, mais le résultat est différent de celui fait dans un autre mode.

Je suis prêt à parier que c'est un varaible ou un tableau mal initialisé. C'était le cas d'un utilisateur il y a environ un mois sur codeguru (où tu as aussi posté cette question et où je t'avais répondu avant de voir que tu étais ici, où il y a plus de monde).
Montre le code qui pose le problème, et quelqu'un trouvera la cause.

Le fait d'exécuter depuis l'IDE a d'autres impacts, quelque qoit la méthode. J'ai déjà un exe qui plantait si on l'exécutait seul, mais pas depuis VC++, que ce soit release ou debug, F5 ou CTRL+F5. C'était dû à une mauvaise taille d'allocation.
J'en ai déduis que VC++ trappe la CRT qui se comporte différement au niveau des allocs, afin de détecter les problèmes etc...
Y'a le répertoire courant qui change aussi je crois.
En tous cas, de tout ce que j'ai entendu, a chaque fois, le code était en cause.
Pour les infos de débogage, y'en a de plusieurs types.
http://msdn.microsoft.com/library/ [...] pdebug.asp
ça va du pas grand chose juqu'à l'Edit & Continue (modification en live du code compilé).

theShOcKwAvE  a raison, moi j'ai déjà ce problème (en release avec F5 ça marche et ctrl-F5 ça ne marche pas), c'est typiquement un poblème memoire, essaie de voir si tu fais autant new que de delete, de malloc que de free, et vérifie aussi si tu lis sur chaînes que la taille de ta variable est assez grande pour lire les données aussi bien en cas nominal qu'en cas d'erreur.
Mais le mieux c'est que tu situes ton pb (en ajoutant des message box par exemple) et ainsi se  pencher plus érieusement sur la question car tout ça n'est que supposition .

Je vais essayer de répondre au mieux, au plus vite :
 

Je n'utilise aucun new, ni delete, ni malloc, ni free. Tout se fait tout seul    
 

Je ne l'ai pas fait, mais dans ce cas, il doit y avoir des erreurs lors du run time, non ? (Parce que moi, tout se passe bien, c'est juste le résultat qui n'est pas bon).
 

Pas con. C'est quoi la commande ?
 

Comme je le dis ci-dessus, le run time se passe bien, ce n'est donc pas (je pense) un problème de répertoire.
 

Je vais y jeter un coup d'oeil.
 

Qu'est-ce que tu entends par mal initialisé ?
 

Il y a un poil trop de code pour être mis sur forum, mais si vous avez des exemples d'initialisation mal faites, je suis prêt  à les lire.

si ton code est compact, tu ne veux pas le poster, qu'on t'aide à le corriger ? (j'imagine mal un code énorme qui n'utilise pas d'allocation dynamique)

il gère l'allocation mémoire tout seul (i.e. je n'ai écrit aucun new ou delete dans mon code) et du coup il n'est pas compact  

 

 
Edit : technique de pointeurs évolués ? Il y a, logiquement, une partie de ton code qui en fait, non ?
Edit 2 : à moins que tu ne laisses tout sur la pile

lol, je ne connais pas la terminologie exacte, mais je ne fais que lire un fichier svg et mettre les infos contenues dedans dans des containers de la stl.
 
Voici un exemple de code que j'utilise :
 
(Edit : ce code ne m'appartient plus - je l'ai retiré)
 
(ouf,   pas pratique l'indentation de MS VC++)
Tout le code n'y est pas, (y'en a pour un paquet de lignes), mais voilà où se trouve le problème.
 
Alors, une idée ?

Bon je n'ai pas trop de temps pour saisir tout ton code mais essaie de faire des AfxMessageBox("Step Ok" ) par exemple pour localiser ton pb et après on pourra en parler

Je suis dessus avec le pas à pas pour essayer de voir ce qui pourrait poser problème.

si tu ne fais pas d'alloc dynamique, es-tu sur de ne pas garder de référence (ou pointeur) sur une variable temporaire ?

si les insertions et les push_back de la stl font des copies et ne prennent pas de pointeurs, alors normalement c'est bon.

bonjour les perfs, aussi J'espère que tes svg ne sont pas trop gros ...

pour l'instant je bosse sur des fichiers de 500ko, mais ça peut aller jusqu'à 5Mo
 
Je suis preneur pour toute optimisation du code (d'ailleurs, si vous avez un lien donnant des méthodes pour optimiser le code je suis preneur).
 
PS : en fait il me fait des modifs sur plusieurs de mes (gros) algos dont un avant (si ça se trouve, j'ai une mauvaise déclaration à un endroit et l'erreur se répercute partout... je continue à chercher)
 
Edit : mais le code est du même style alors si vous voyez des erreurs, n'hésitez pas !!

bah, vu que tu demandes (je n'ai pas lu en détail) :
 
* évite les instance temporaires et les recopies inutiles (par exemple : dupliquer des vecteurs de points, ca peut finir par être coûteux, à force)
 
* évite les cast C (du style nLOPIndex += (unsigned int)tmpLop.size())
 
* je m'emmêle dans tes itérateurs quand je cherche à comprendre

Moi j'ai souvent eu ce problème de release et je l'ai toujours résolu, mais malheureusement je ne travaille pas avec les stream (je deteste ça), c'est presque du chinois pour moi  donc je n arrive pas à comprendre ton code

je ne vois pas de stream dans son code ...

une ligne de mon code à citer ?
 

tu remplacerais ça par quoi ?
 

C'est parce que la le container est assez compliqué (un multimap<string, vector< vector< pair< float, float> > > >   )
 
Edit : pour compléter mon message

J'ai trouvé le problème (enfin), merci beaucoup à vous tous pour votre aide . C'était effectivement un accès à une case mémoire qui avait été au préallablement effacée .
Ce que je ne comprends pas, c'est pourquoi alors que ça aurait dû planté en Debug (parce que j'essayais d'accéder à une case mémoire inexistante) ça ne plantait pas, et même pire, ça donnait le bon résultat    !!
 
VC++ lis-t'il dans mes pensées les plus profondes pour exaucer mes souhaits ?    

alors c'est marrant, parceque généralement, un accès foireux risque de passer en Release et pas en Debug....
 
tu peux poster le code avant & après correction ? (juste par curiosité)

En Debug il alloue un peu plus que ce que tu demandes.

oué c'est vrai, mais justement il en profite pour poser des marqueurs pour tester les débordements.
 
alors après ptet qu'un débordement en lecture ne poses pas de problèmes...

Tu as une option dans le dernier VC++ pour vérifier les accès out of bound je crois (principalement pour prévenir les exploits).  
 
Évidemment ça ne marche pas bien avec les structures comme les vectors qui font leur propre allocation dynamique (dans ce cas ces structures devraient inclure elles-meme la verification d'accès out of bound mais ce n'est pas compatible avec la notion d'itérateur). Enfin ça limite le risque d'exploits mais ça n'enlève pas les bugs.
 
Sinon une erreur classique avec les vector c'est de conserver les itérateurs après une insertion/deletion/reallocation. L'itérateur étant un pointeur la plupart du temps, le pointeur devient invalide après une réallocation (Erreur qui n'est pas toujours intercepté parce qu'un pointeur invalide peut pointer vers une zone mémoire valide !).
 
Et surtout ces aides à la programmation ne sont qu'un outil parmi d'autres parce qu'une fois ton programme dans la nature tout peut arriver..

Je crois que l'option dont tu parles n'est applicable que pour la pile (création d'un "cookie" ), pas pour le tas.

désolé, je n'ai plus la version d'avant
 

Déjà fait    

Et aucun moyen de savoir qu'un itérateur sorte du vector ?

Edit :
Au fait, personne ne serait au courant d'un différence de fonctionnement entre Debug et Release lors de l'utilisation de float ?
(lors de calculs ou d'un fprintf(monFILEetoile, "%.2f", 123.45f) )