J'uilise Bloodshed Dev-C++ 4.9.9.2 pour mon petit programme en C qui doit
ensuite tourner sur un serveur NT4. J'ai déjà mis en production sur mon
serveur NT4 une première version de mon programme en C il y a maitenant
plusieurs mois et il tourne bien.
Le problème c'est que je veux faire évoluer mon programme et le debugueur
pas à pas marche mais quand il veut !! .
Il n'y a pas une option pour lui dire de mieux fonctionner sous XP ou un
autre compilateur pas pas capable de faire le même job ?
Même l'utilisation demesurée du stack simplement par l'appel de fonction se termine souvent par un signal 11, et quand bien même on voit le message 'stack overflow', ça fait une belle jambe. Personnellement, je n'ai dépassé inintentionnellement la taille du stack qu'en phase de premier test d'une fonction récursive dans laquelle j'avais malencontreusement mal codé le test d'arrêt, alors allouer 1Kb dans le stack, quelle plaisanterie lorsqu'on est dans une fonction qui n'en appelle pas d'autres. [...]
Allouer 1Ko ne pose aucun problème, c'est clair. Et sous les unix/linux, on alloue en pile à peu prêt autant qu'en stack, donc la quantitée de mémoire n'est pas le problème.
Mais sous windows, c'est faux. Je peux avoir 100Mo, 300 Mo en stack facilement, définitivement pas en pile, et si je laisse distraitement le paramètre par défaut, pas plus de 1Mo.
De plus diagnostiquer les débordement de buffer pose des problèmes avec cette solution.
Il ne s'agit pas de discréditer absolument alloca, simplement de bien prendre la mesure des avantages face aux risques et d'agir en connaissance de cause.
Ce qui permet d'éviter les problèmes qui justement vont donner mauvaise réputation à alloca à ceux qui partent sans être au courant des précautions à prendre.
Harpo wrote:
Même l'utilisation demesurée du stack simplement par l'appel de fonction
se termine souvent par un signal 11, et quand bien même on voit le
message 'stack overflow', ça fait une belle jambe.
Personnellement, je n'ai dépassé inintentionnellement la taille du stack
qu'en phase de premier test d'une fonction récursive dans laquelle
j'avais malencontreusement mal codé le test d'arrêt, alors allouer 1Kb
dans le stack, quelle plaisanterie lorsqu'on est dans une fonction qui
n'en appelle pas d'autres.
[...]
Allouer 1Ko ne pose aucun problème, c'est clair. Et sous les unix/linux,
on alloue en pile à peu prêt autant qu'en stack, donc la quantitée de
mémoire n'est pas le problème.
Mais sous windows, c'est faux. Je peux avoir 100Mo, 300 Mo en stack
facilement, définitivement pas en pile, et si je laisse distraitement le
paramètre par défaut, pas plus de 1Mo.
De plus diagnostiquer les débordement de buffer pose des problèmes avec
cette solution.
Il ne s'agit pas de discréditer absolument alloca, simplement de bien
prendre la mesure des avantages face aux risques et d'agir en
connaissance de cause.
Ce qui permet d'éviter les problèmes qui justement vont donner mauvaise
réputation à alloca à ceux qui partent sans être au courant des
précautions à prendre.
Même l'utilisation demesurée du stack simplement par l'appel de fonction se termine souvent par un signal 11, et quand bien même on voit le message 'stack overflow', ça fait une belle jambe. Personnellement, je n'ai dépassé inintentionnellement la taille du stack qu'en phase de premier test d'une fonction récursive dans laquelle j'avais malencontreusement mal codé le test d'arrêt, alors allouer 1Kb dans le stack, quelle plaisanterie lorsqu'on est dans une fonction qui n'en appelle pas d'autres. [...]
Allouer 1Ko ne pose aucun problème, c'est clair. Et sous les unix/linux, on alloue en pile à peu prêt autant qu'en stack, donc la quantitée de mémoire n'est pas le problème.
Mais sous windows, c'est faux. Je peux avoir 100Mo, 300 Mo en stack facilement, définitivement pas en pile, et si je laisse distraitement le paramètre par défaut, pas plus de 1Mo.
De plus diagnostiquer les débordement de buffer pose des problèmes avec cette solution.
Il ne s'agit pas de discréditer absolument alloca, simplement de bien prendre la mesure des avantages face aux risques et d'agir en connaissance de cause.
Ce qui permet d'éviter les problèmes qui justement vont donner mauvaise réputation à alloca à ceux qui partent sans être au courant des précautions à prendre.
Antoine Leca
In news:dnn5m7$ecp$, Jean-Marc Desperrier va escriure:
Allouer 1Ko ne pose aucun problème, c'est clair.
Non.
Et sous les unix/linux, on alloue en pile à peu prêt autant qu'en stack,
:-)))
Mais sous windows, c'est faux. Je peux avoir 100Mo, 300 Mo en stack facilement, définitivement pas en pile, et si je laisse distraitement le paramètre par défaut, pas plus de 1Mo.
Dépend pas du compilateur (ou de l'implémentation de alloca()), cela ?
Antoine
In news:dnn5m7$ecp$1@reader1.imaginet.fr, Jean-Marc Desperrier va escriure:
Allouer 1Ko ne pose aucun problème, c'est clair.
Non.
Et sous les unix/linux, on alloue en pile à peu prêt autant qu'en stack,
:-)))
Mais sous windows, c'est faux. Je peux avoir 100Mo, 300 Mo en stack
facilement, définitivement pas en pile, et si je laisse distraitement
le paramètre par défaut, pas plus de 1Mo.
Dépend pas du compilateur (ou de l'implémentation de alloca()), cela ?
In news:dnn5m7$ecp$, Jean-Marc Desperrier va escriure:
Allouer 1Ko ne pose aucun problème, c'est clair.
Non.
Et sous les unix/linux, on alloue en pile à peu prêt autant qu'en stack,
:-)))
Mais sous windows, c'est faux. Je peux avoir 100Mo, 300 Mo en stack facilement, définitivement pas en pile, et si je laisse distraitement le paramètre par défaut, pas plus de 1Mo.
Dépend pas du compilateur (ou de l'implémentation de alloca()), cela ?
