Bonjour a tous,
 
Je voulais juste connaitre la difference entre les programmes scompiles en mode Debug et en mode Release. Ce que j'ai pu voir : la taille du .exe et la rapidite d'execution (+ rapide en Debug, mais bcp + gros) ...
 
 
Il doit bien y avoir autre chose !
 
Merci d'avance

Debug c'est pour faire du debug, et release c'est pour faire une release.

...et j'avais pas fait gaffe, mais plus rapide en debug ça m'étonnerait bcp!

oui ca m'etonne aussi

En Debug, le compilo insère dans le code une multitude d'infos te permettant de surveiller le soft, de le stopper avec des breakpoints, de capturer les exception etc...
 
Ceci alourdi l'executable et le rend un peu plus lent.
 
En release il n'y a que le code utile, donc c'est + petit et + léger mais moins "sécurisé" donc il faut simplement développer en debug et livrer en release.
 
Note bien que selon des infos de debug inscrites dans l'exe, il peut être illégal de fournir un debug à un tiers car les données de debug ne sont pas toujours redistribuables. C'est notament le cas de visual c++

Une petite précision. Certains programmes ne fonctionne pas dans le mode Release par défaut de VC++ 6.0. Seul le mode Debug le permet. Donc on modifie le profil du mode Release pour le rendre identique au mode Debug, mais sans les informations de traçage.
 
Enfin, lors de la programmation de routine en asm, le mode Debug est plus tolérant sur l'utilisation des registres. En mode Release, c'est plus calamiteux (il faut toujours sauver ebx voire les autres registres...).

C'est que le Debug n'optimise pas. C'est pour ça qu'il est plus lent (en fait c'est release qui est plus rapide) et que trifouiller l'asm ne pose pas trop de pblm en Debug. Les allocations sont différentes aussi : des vérif sont faites, etc...
Quels prog ne fonctionnent pas en mode Release ?

 
Ceux qui débordent hors de la mémoire qu'ils allouent

 
Ceux qui présupposent que tout est alloué à 0 ?

Aussi

ça au passage C -> C++ ça fait mal, j'en sais qqchose ...    
 

le debug de vc 6.0 met tout à 0xCCCCCCCC (1010101... en binaire), pas à 0.
 
désassemble le binaire produit par un debug, tu verras plein de

Il le fait que pour les variables sur la pile. 0xCC correspond à int 3h qui est une instruction de debug (program break).
Pour les variables static/global, je crios que c'est selon l'OS. VC++ ne fait rien d'autre que placer en section non initialisée, initialisée à zéro sous NT et pas sous 9x me semble-t-il.
http://msdn.microsoft.com/library/ [...] _build.asp
http://www.flounder.com/debug_release.htm

Dans tout les cas, utilisez les assertions !

Non
C'est crade, et si on oublie d'en virer une en mode release, ça rend le débuggage immonde car le message d'assertion échouée n'apparait pas en mode Release !
Et surtout, ça permet d'éviter au programmeur flemmard la programmation d'une gestion d'erreur digne de ce nom ! ("Toutes mes assertions passent en mode Debug ? Parfait, je vais pas me casser le cul avec des exceptions" ).
Bref, rien ne vaut une gestion des erreurs à base d'exception, pas ces trucs immondes d'assertions made in MFC

les seules assertions utiles sont les compile tim eassertion.
Le reste ca sert a rien, les exceptions sont bien meilleur.

En général, j'utilise les exceptions dans les fonctions membres public, les assert sinon.

C'est koi une compile time assertion ?

une assertion qui se declenchent à la compilation.
 
http://www.boost.org/libs/static_a [...] assert.htm

Non. Les assertions c'est bien, mangez en.
 
Rien de tel pour débugger un programme. Ca fait gagner un temps fou lors du dev. Et une assertion qui claque, c'est une rupture de contrat, donc un comportement anormal. Mieux vaut arrêter le programme, corriger le code, et reprendre plus tard. Et sous unix, l'assertion a le bon gout de produire un fichier core que tu peux analyser par la suite.  
 
Une exception & une exception, ça n'a pas la même utilité. Ce sont 2 principes très différents.

 
mouais certes .... mais la plupart des assertions se remplacent naturellement par de simples tests de pre ou post conditions.

 

C'est pas spécifique aux MFC les assertions (la macro assert() existe en ANSI C, par exemple).
Moi je trouve ça relativement pratique... faut dire que la gestion des exceptions en C

pour une fois je te prends pas en défaut

... juste pour ce qui comprendrais pas, par assertion, il faut  surtout pas entendre la macro assert du C

 
Quelqu'un a parlé de la macro assert() du C ici ?
 
Pourquoi ce n'est pas comparable On m'aurait menti ?

parce que assert stop brutalement ton programme
parce que les assert son réduits en Noop en mode non-debug

 
j'ai compris maintenant ^^

1. la plupart -> ok.
2. les pre et les post conditions ne peuvent pas toujours être évaluées à la compilation, loin s'en faut. Il faudrait que je jette un coup d'oeil au lien que tu as donné sur boost, car l'interêt me semble minime (je n'ai pas dit nul): ces pre/post conditions ne peuvent bien souvent être vérifiée qu'à l'execution.

c'est justement l'intêret. Pourquoi continuer le programme alors qu'il y a une rupture de contrat. Quand on est en mode debug, alors meiux vaut arrêter tout de suite et debugger l'erreur qui vient de se produire, non? L'execution du programme se trouve peut être ralentie par tous ces tests, mais je suis prêt à en payer le prix si la qualité du debuggage s'en trouve améliorée. Et en plus, il n'en restera plus 1 trace en mode non-debug. parfait!

pourquoi ? parce que tu as un utilisateur, parce que tu as acquis des ressources et que tu dois les libérer selon un certain protocole.
 
perso, je rajoute des assert quand vraiment je debug, mais loin de moi l'idée d'écrire du code truffé d'assert à la con / sert à rien directement.
 
et même, je ne trouve pas les assert C pratique, je préfère une jolie exception qui remonte. d'autant plus que je ne vois pas pourquoi tu n'as besoin de respecter ton contrat qu'en mode debug ...

pour la libération des ressources, si vraiment tu as un soucis avec ça, alors ok. Peu de programmes ont vraiment cette contrainte je pense. La plupart des ressources systèmes sont libérées par l'OS à la sortie du programme si cela n'a pas été fait explicitement. Mais parfois...
 
L'avantage de l'assert C, c'est que ça fait crasher le programme à l'endroit où le contrat est rompu et qu'on récupère tout le contexte d'exécution. On sait où a eu lieu le problème et on connait sa nature exacte. C'est gentil de récupérer une exception, mais t'en fait quoi? Tu refile le bébé à qqun d'autre? Un gestionnaire d'exception qui ferme les ressources proprement et qui dit au-revoir? En release ok, mais pas en debug. Je prefère avoir le contexte de plantage et gagner un temps précieux.
Ceci dit, je suis bien d'accord avec toi: tu n'as pas plus besoin de respecter ton contrat en mode debug que dans un autre mode. Par contre, en debug, on peut(doit?) se permettre de vérifier les contrats un peu plus souvent. Ca permet de vite trouver les erreurs d'étourderies et autres bêtises de copier/coller malheureux. En plus, un contrat bien formulé permet de laisser un code plus lisible pour ceux qui doivent passer derrière.

déjà ce n'est pas le cas pour les descripteurs de fichiers, après tu peux posséder des verrous ou avoir établis des connexions (réseau, sgdb) pour lesquelles il faut suivre un protocole. et pense à ton utilisateur. on ne vérifie pas de contrat avec des assert. on s'en essentiellement pour vérifier que le programme tourne bien comme on le pense, pas par pas

>  déjà ce n'est pas le cas pour les descripteurs de fichiers
ah? tu m'étonnes là... faudra que je vérifie quand même
 
> après tu peux posséder des verrous ...
je me répète, mais dans ce cas, ok... et encore, si tu as un client serveur avec un serveur qui ne supporte pas la déconnexion brutale de ton client, y'a comme un pb. Change de serveur, sinon à la première coupure réseau il est en rade...
 
> et pense à ton utilisateur
justement, je pense à lui! Plus mon programme sera debuggé, moins l'utilisateur d'une version "de production" sera confronté à des bugs. Une verison de production et une version de debug, ce n'est à mon sens pas tout à fait la même chose.
 
> on ne vérifie pas de contrat avec des assert
en mode debug on fait une première vérification avec le assert et en plus on crash si le contrat n'est pas vérifié. Si la vérification du contrat doit être faite en mode non-debug aussi, alors on rajoute après la vérification du contrat qui génère une exception en cas de rupture
 

c'est pas une raison pour quitter brutalement si tu peux l'éviter. si tu debug ton programme, tu peux envisager de le planter 2/3x par minutes ...
 
dans tous les cas avec tes assert, tu l'as dans l'os ... va t'en faire des tests unitaires avec des assert, reviens après

si, c'est une bonne raison parce que tu identifies la source du problème immédiatement. je trouve donc cela franchement plus simple pour localier l'erreur, et donc plus rapide pour corriger.
donc l'assert c'est bien dans *presque* tous les cas
 
je vois pas en quoi ça pose un problème pour faire des tests unitaires. De toute façon ça rime à quoi de faire des tests unitaires avec un programme si tu sais qu'il est bancal. Qui te dis qu'il se comportera encore de la même façon une fois que tu aurras coorigé le 1er problème.
En debug, préferrer continuer plutôt que de s'arrêter, je ne vois pas l'interêt.

et bien quand tu as une batterie de tests, planter sur le premier problème, ça t'empêche justement d'observer globalement le problème. avec ton gentil assert, tu va te focaliser pour que bordel de merde, ça plante plus sur ce putain d'assert, tu  vas tout faire et si ça se trouve du même coup casser sans le savoir une autre partie de ton composant

Ben assert est exception c'est pas fait pour la même chose. L'assertion n'est pas faite pour vérifier des paramètres / checker une allocation.
L'assert est pour moi plus proche du commentaire que de la vérification.
assert( condition );
Indique qu'à ce point dans le programme, si tout a été fait comme il faut, condition est toujours vrai. Autre utilité, le fait que ça dégage en Release, pour rajouter du code de vérif supplémentaire. C'est comme ça sous VC++ par exemple que la lib test si tu delete 2 fois de la mémoire, etc...
Je les trouve très utiles dans les classes de base, car quand on la dérive qq demaines plus tard, on a vite fait d'oublier un truc à la con qui va te prendre plusieures heures à trouver.
Exemple bête :

Peut importe ce que fait cette classe, disons qu'elle gère une lecture bufferisée de fichier. Elle sert de base à d'autres classes.
Le contrat, comme dit SoWhatIn22, c'est que le buffer ne sert que pendant la lecture. Comme il est volumineux, il convient de le libérer dès qu'on n'en n'a plus besoin.
Donc on doit pas arriver au destrcuteur avec un buffer plein.
Mais si ça se produit, ben on le libère, sans tout faire planter. Mais en Debug il est bon de signaler qu'il faut le libérer plus tôt.

bah non: si tu tombes sur ce problème, tu essayes d'en comprendre la cause. Le contrat te donnes l'erreur, à toi d'en trouver la cause. Si le contrat est rompu, c'est que ya eu un pb avant l'erreur, pas après je ne comprends pas en quoi continuer à éxécuter le programme va t'aider à localiser le problème.

moi je parle qu'il faut banir les assert à tout prix
 
mais je reste perplexe devant ton exemple

ben si justement...

nan nan, je t'assure que je n'ai pas compris