Mon programme marche en debug, mais pas en release, je suis perdu

C'est pas "il FAUT", mais il y a des principes à appliquer qui sont positifs sur de nombreux aspects ( performance, maintenance, ... ). Il y a un principe de conception qui s'appelle SOLID.
C'est un acronyme, le premier S signifie "Single Responsablity Principle" (Principe de responsabilité unique), qui dit que chaque fonction, chaque classe, chaque structure à une responsabilité unique, par exemple, une fonction d'addition de 2 vecteur 3D ne fait que ca. Là, dans ton main, tu as toutes les responsabilités dans 1 seule fonction. Je te laisse regarder les autres lettres sur le net.

Tu dois découper, reflechir sur le cycle de vie de ton application ( Initialisation, traitement, libération), deja rien que la tu peux avoir 3 fonctions.

Il n'est pas rare de voir un main qui ne fait que créer un objet application et qui lance juste une seule fonction ( run() ).

pour répondre a ton EDIT : d'où pourrai-je savoir d'où vient mon pb , car il n est levé aucune exception d'aucune sorte, et je me trompe pas dans mes tableaux littérateurs ects car ca se voit tres bien a l essai et a l utilisation les erreurs de ce genre....


sachant aussi que dans le debuggeur visual studio, la plupart de mes variables sont absentes de la fenêtre de visualisation des locales, ceci que en release, en debug, j ai toutes mes variables présentes et tout marche du coup on dirai, car en release, même au moment ou il ne marche plus il plante pas , pas d'exceptions levées, il fait quand même sa boucle générale au jeu quand même.

Ca pourrait fixer ton problème si tu règles ce problème.
Une lecture à faire pour ce qui concerne les stack frames. A ne pas confondre avec la stack.

http://www.qnx.com/developers/docs/q...ackFrames.html

bonjour, j ai fait une version de mon prog avec des allocations dynamiques pour les tableaux que tu m avais fait remarque et ca change pas /analysestack.... toujours le meme nombre, 46 ko, je vous dis en version classes ce que ce donnera...

Bonjour !!!

A propos de la lecture que tu m'a indique, j ai essayé de mettre comme indiqué l'omission des stack de frames dans les options du compilateur comme ceci :


Pièce jointe 602093



cela ne change rien du tout ...

Au lieu de jouer avec les options, fais marcher ton code avec les options par défaut

Je l ai fait, j'avais refait un projet/solution avec les options par défaut du compilateur et éditeur de lien, rien n' y a fait et ceci sur 3 ordis différents, un win 7, un win 8.1 et l'autre win 10 , c 'est toujours pareil !!!!!!

je crois je vais attendre de finir ma versions en classes pour voir si ça change...

c'est gentil de chercher à m aider en tout cas ...

P;S : Est ce que un petit excès de inline utilisé à la place des macros peut être à l'origine de mon pb ????

Non, ça ne peut-être que mieux.

Je vais me répéter mais ce qui fait qu'un programme release n'a le même comportement qu'en debug, c'est que le code contient des "comportements indéfinis", autrement dit des actions qui ont un résultat imprévisible. Et ici l'aléatoire donne un résultat qui semble correct en debug, et qui ne l'est clairement pas en release. Un exemple:

Code:

---

1 2 3 4 5 6 7

int main() { int i; if ( i != 0 ) std::cout << "hello"; else std::cout << "ciao"; }

---

Ce code peut tout à fait afficher "hello" en debug et "ciao" en release, ou l'inverse ou autre. Si tu voulais "hello" tu diras ma version debug marche, celle release ne marche pas. Mais l'erreur est dans le code qui n'a jamais initialisé i.

bonjour, mon programme n'as pas l'air d'avoir de situation indéfinie, car un endroit précis, il agit toujours de la même manière, j initialise tout, et je laisse pas "conceptuellement" ce cas s'insérer dans mes programmes. et la seule différence, c est que sur la version win 7 j ai des messages d'erreurs de la sdl qui me dit que les threads n'ont pu être instancies par manque de "ressources" (terme employé par la sdl ).
tout me semble bon dans mon prog.

P.S : en mettant la version release sans aucune optimisation, toutes mes variables locales au main "apparaissent " dans le debugger et j ai pu suivre le cheminement de mon programme, et je comprends pas, il agit, à un moment, comme un gros écrasement de pile qui signale rien au debugger...


P.P.S = quand la seule chose que je change dans mon projet release x64 c 'est de remplacer la directive préprocesseur de NDEBUG à _DEBUG tout marche impeccable...

En Fait, j ai trouvé la solution, j avais une ligne entre #ifdef _DEBUG et #endif _DEBUG qui ne devait pas s'y trouver , c'est tout bête et très logique par rapport à mon prog ( je mets toutes sortent de messages et "vérif." uniquement en debug par ce ce biais et je me suis trompé, ça m'a permis de faire de la lecture, j'adore la doc lol ...

ça me rassure j ai horreur des situations indéfinis, je fais tout pour les éviter, ça m'a permis d'en savoir plus sur les compilateurs et ect ...


j ai une dernière question à propos des cas indénis :

si je manipule un unsigned int8 NB donc plage qui va de 0 à 255, et que je fais NB = 0 puis après NB = NB -1, que devient mon unsigned int8 , -1 donc cas indéfini, donc bug, erreur ect , ou il se met au minimum de sa plage ç a d 0 et dans ce cas pour mon prog c'est bon ?????

Là tu dois aller lire la doc sur la two-complement representation des entiers.
Le dépassement des limites non signé sont des UB en C et C++, ce qui permets dans certaines situations d'autoriser le compilateur à faire des optimisations qu'il ne peut pas faire avec les versions signée car il DOIT gérer dans ce cas les dépassements.
Pour les versions signées c'est défini, c'est défini.
La représentation complément à deux fera la taf correctement ( Si ton système est bien en complément à deux, mais perso je n'ai jamais croisé autre chose )

Un exemple sur godbolt https://godbolt.org/z/r3cKchrn4

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include<cstdio> int main() { // Signed char est de [-128, 127] signed char i = -128; volatile signed char overflow_i = i-1; // Overflow de i, ça boucle printf("signed char overflow %i\n", overflow_i); // Signed char est de [0, 255] unsigned char j = 0; volatile unsigned char overflow_j = j-1; // Overflow de j, ça boucle aussi printf("unsigned char overflow %i\n", overflow_j); return 0; }

---

Citation:

---

Envoyé par ArnaudNRoses

J ai effectivement mis l'optimisation pour un code plus rapide, car c est un jeu "en temps réel" ( un shoot them up ), je sais pas il optimise comme tu dis, vu qu 'il manque vraiment beaucoup de variables locales dans le visualiseur des variables du débuggeur , même mes littérateurs dans les boucle for , alors que le programme fonctionne quand même sans planter. pour visual studio et mon pc mon programme plante pas et fais pas d'exceptions ( lol d'ailleurs !!!), il manque juste beaucoup de décors, les threads se lance pas ect....

la fonction qui pose problème, c est le main ... et que elle d'après IntelliSense de chez bilou...

---

Je pourrais quote un autre message , mais c'est représentatif de tes messages , c'est écrit un peu comme "oui mais je fais un truc spécial et complexe" , alors déjà pas mal de monde d'ici on fait du jeux vidéo en pro :)
Et sinon non un shoot them up n'est pas incroyable à faire et ça ne demande rien de spécial qu'un autre jeu actuellement , vu que j'en ai fait un sur une pauvre SNES.

Même si sur PC tu es beaucoup plus à l'aise et normalement ça devrait jamais ramer , sauf si tu programme avec des pieds :D

Citation:

---

Envoyé par ArnaudNRoses

dans la pile, J ai beaucoup de tableaux à 2 ou 3 dimensions qui sont que des pointeurs ( 8 octets ) et ces pointeurs pointent sur des objets alloués eux dynamiquement dans dans le tas

---

Étonnant que personne ne l'est souligné , mais y'a de grande chose que c'est l'origine du bug , utilise un debuggeur , vu que ton soucis semble vraiment être un segfault :)