Re: Un bug dans la STL ?
Quoting Julien Gilles Oula, C++ ... Pourquoi se créer des problèmes inutilement ? ;-) C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg - B. Stroustrup Joli :-) Cependant, je reste persuadé qu'un bon développeur doit pouvoir s'accomoder de n'importe quel langage. :-) -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Un bug dans la STL ?
Jérôme Marant, 2005-04-29 08:40:11 +0200 : Cependant, je reste persuadé qu'un bon développeur doit pouvoir s'accomoder de n'importe quel langage. :-) Après avoir passé la semaine dans un combat sans merci contre TCL, je souhaiterais apporter un bémol à cette affirmation :-) Roland. -- Roland Mas With the arrest of Dimitry Sklyarov it has become apparent that it is not safe for non US software engineers to visit the United States. - Alan Cox -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[résolu] Re: [HS] Re: Un bug dans la STL ?
Scribit Guillaume Morin dies 28/04/2005 hora 23:26:
Tu dois retourner une *référence* sur ton Dice pas un nouvel objet. En
effet, tu vas créer des objets temporaires (un par appel a ) qui
référencent le même vecteur.
Non, car ayant surdéfini l'opérateur =, il n'y a pas de copie
superficielle. Néanmoins, merci de la remarque, c'est corrigé. Le
problème venait probablement du fait que mon constructeur de recopie ne
créait pas le vecteur, en fait. C'est corrigé, et cette partie du code
fonctionne désormais, semble-t-il.
Par contre, je suis tombé sur troisième bug dans mon code, et je suis
effaré que le compilo soit passé outre :
templateclass T Dice operator =(const T )
{
m_rollable_scalars-clear();
this-append(value);
return *this;
}
value aurait du être l'identifiant de l'argument, mais j'avais oublié,
une fois que j'ai décidé d'en faire une fonction template définie dans
le fichier d'en-tête, de le rajouter dans ce qui était le prototype.
C'est un bug dans GCC, ou c'est parce que c'était une fonction
template ?
Si tu avais conçu ta classe correctement, tu aurais repérer le prb
tout de suite. Les versions de l'opérateur= et du constructeur par
recopie générés par le compilateur ne sont pas correctes pour l'objet
Dice. Tu dois donc les écrire toi même si tu veux autoriser la copie
d'objet Dice.
C'était déjà fait.
Merci d'avoir pris le temps d'étudier mon problème.
Finalement,
Nowhere man
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
Re: [résolu] Re: [HS] Re: Un bug dans la STL ?
Dans un message du 29 Apr à 22:41, Pierre THIERRY écrivait :
Tu dois retourner une *référence* sur ton Dice pas un nouvel objet. En
effet, tu vas créer des objets temporaires (un par appel a ) qui
référencent le même vecteur.
Non, car ayant surdéfini l'opérateur =, il n'y a pas de copie
superficielle.
Nan ca n'est rien a voir. Quand tu retournes un objet par valeur, le
constructeur par recopie est appele (sauf si ton compilateur peut
utiliser la return value optimization, mais ce n'est pas le cas ici) et
pas l'operateur d'assignement qui n'est appele que pour les objets
*deja* construits.
exemple:
A a;
A aa = a; // appelle le cteur par recopie et pas operator=
A aaa(a); // pareil
aa = a; // appelle operator= car aa deja construit
Néanmoins, merci de la remarque, c'est corrigé. Le problème venait
probablement du fait que mon constructeur de recopie ne créait pas le
vecteur, en fait. C'est corrigé, et cette partie du code fonctionne
désormais, semble-t-il.
Ca ne changera pas le schmilblick. Ta chaine d'appel de l'operator
ne fonctionnera pas comme prevu si tu ne renvoies pas une *reference*.
Sinon tu vas creer des objets temporaires a la chaine et ton objet de
depart ne sera appele que la premiere fois.
Pourquoi crois-tu que tous les operateurs , et = standards
renvoient des references?
De plus, tu dois aussi dupliquer les objets pointes sinon quand tu fais
une copie d'un Dice, sinon la destruction d'un des objets va invalider
l'autre (sauf si tu laisses la memoire fuir).
Par contre, je suis tombé sur troisième bug dans mon code, et je suis
effaré que le compilo soit passé outre :
templateclass T Dice operator =(const T )
{
m_rollable_scalars-clear();
this-append(value);
return *this;
}
value aurait du être l'identifiant de l'argument, mais j'avais oublié,
une fois que j'ai décidé d'en faire une fonction template définie dans
le fichier d'en-tête, de le rajouter dans ce qui était le prototype.
C'est un bug dans GCC, ou c'est parce que c'était une fonction
template ?
C'est parce que le compilateur n'est pas oblige d'instancier ton
template lors de sa declaration (et en pratique peu de compilateurs le
font). Ton code ne l'instanciant jamais le compilateur ne t'a pas donne
d'erreur. (C'est au passage la preuve que ce que je te disais dans mon
precedent message est vrai).
Au passage, ton operateur= ne fonctionne pas correctement pour
l'aliasing. (Si je me souviens bien, c'est le cas de tous tes operateurs
d'assignement).
Ta methode elements() retourne une copie du vecteur de pointeurs donc
n'importe quel client de ta classe peut appeler delete sur les pointeurs
et donc faire planter le programme.
--
Guillaume Morin [EMAIL PROTECTED]
Justice is lost, Justice is raped, Justice is done. (Metallica)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Un bug dans la STL ?
Jrme Marant [EMAIL PROTECTED] writes: Pierre THIERRY [EMAIL PROTECTED] writes: Hello, je suis en train de me mettre crire une bibliothques de classes en C++, qui me servira ensuite pour des logiciels de jeu (principalement du jeu de rle). Oula, C++ ... Pourquoi se crer des problmes inutilement ? ;-) C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg - B. Stroustrup -- Julien Gilles.
Re: Un bug dans la STL ?
Scribit Vera Mickael dies 27/04/2005 hora 19:29: Tu as dû faire une erreur de programmation. Peut-être, mais même avec valgrind, impossible de comprendre où est mon erreur. Je sais précisément où ça merde dans mon programme. Plus précisément, ça merde au final dans la STL (à cause de moi ou d'un bug en elle-même...), et je sais où est l'appel dans mon source (dans la méthode clear() de la classe Dice). Mais je ne vois pas quoi corriger. Si je décommente l'instruction qui, avant de supprimer le pointeur du conteneur, désalloue l'objet pointé, alors, avec un conteneur vector, on a plus la taille qui passe de 1 à un nombre astronomique, mais à 104, puis segfault... Infructueusement, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Un bug dans la STL ?
Hello, je suis en train de me mettre à écrire une bibliothèques de classes en C++, qui me servira ensuite pour des logiciels de jeu (principalement du jeu de rôle). Je commence par les dés, et je suis tombé sur un os : une de mes classes comprend un méthode qui est censée désallouer des objets dont les pointeurs sont stockés dans un conteneur de la STL, qui est un membre privé de la classe, et vider celui-ci au passage. Avec trois types différents, j'obtiens trois bugs différents, l'un très grave. Si c'est un vectorMonType*, impossible de vider. un pop_back() quand size() renvoit 1 fait passer à un état où size() renvoit 33635908 (2^25+81476, je trouvais que c'est étrangement « proche » d'une puissance de 2), Si c'est un dequeMonType*, au bout de quelques secondes, la machine plante lamentablement, impossible de passer sur une console texte ou de tuer le serveur X. Seule possibilité, les Magic Keys du kernel, SIUB. Et lorsque la machine redémarre, kernel panic. Un redémarrage supplémentaire et elle démarre comme une fleur. Si c'est un listMonType*, le programme segfaulte après ou pendant la suppression du dernier élément. Je recommande de lancer la version deque ainsi : ./test sleep 4 ; kill %+ Est-ce que quelqu'un saurait me dire ce qui se passe, ou au moins me filer des pistes sur la façon de le découvrir ? Au passage, est-ce que ce n'est pas un bug gravissime dans le noyau (probablement dans l'ordonnancement) qu'un plantage pareil puisse arriver ? Problématiquement, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A dice.tar.gz Description: Binary data signature.asc Description: Digital signature
Re: Un bug dans la STL ?
Un peu HS ton mail ;-) C'est le genre de bugs classiques avec C ou C++ (qui font souvent préférer Java) Je ne pense pas que ce soit un bug de la STL, essaie un outil du style checker (checkergcc) ou electric fence ou valgrind. Tu as dû faire une erreur de programmation. Bon courage, Mickaël Pierre THIERRY a écrit : Hello, je suis en train de me mettre à écrire une bibliothèques de classes en C++, qui me servira ensuite pour des logiciels de jeu (principalement du jeu de rôle). Je commence par les dés, et je suis tombé sur un os : une de mes classes comprend un méthode qui est censée désallouer des objets dont les pointeurs sont stockés dans un conteneur de la STL, qui est un membre privé de la classe, et vider celui-ci au passage. Avec trois types différents, j'obtiens trois bugs différents, l'un très grave. Si c'est un vectorMonType*, impossible de vider. un pop_back() quand size() renvoit 1 fait passer à un état où size() renvoit 33635908 (2^25+81476, je trouvais que c'est étrangement « proche » d'une puissance de 2), Si c'est un dequeMonType*, au bout de quelques secondes, la machine plante lamentablement, impossible de passer sur une console texte ou de tuer le serveur X. Seule possibilité, les Magic Keys du kernel, SIUB. Et lorsque la machine redémarre, kernel panic. Un redémarrage supplémentaire et elle démarre comme une fleur. Si c'est un listMonType*, le programme segfaulte après ou pendant la suppression du dernier élément. Je recommande de lancer la version deque ainsi : ./test sleep 4 ; kill %+ Est-ce que quelqu'un saurait me dire ce qui se passe, ou au moins me filer des pistes sur la façon de le découvrir ? Au passage, est-ce que ce n'est pas un bug gravissime dans le noyau (probablement dans l'ordonnancement) qu'un plantage pareil puisse arriver ? Problématiquement, Nowhere man -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Un bug dans la STL ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pierre THIERRY wrote: Hello, Salut! Si c'est un vectorMonType*, impossible de vider. un pop_back() quand size() renvoit 1 fait passer à un état où size() renvoit 33635908 (2^25+81476, je trouvais que c'est étrangement « proche » d'une puissance de 2), je passe... (-: Si c'est un dequeMonType*, au bout de quelques secondes, la machine plante lamentablement, impossible de passer sur une console texte ou de tuer le serveur X. Seule possibilité, les Magic Keys du kernel, SIUB. Et lorsque la machine redémarre, kernel panic. Un redémarrage supplémentaire et elle démarre comme une fleur. C'est plus qu'un bug STL ça! Cela ressemble plus à une barette de RAM défectueuse ou un problème matérielle quelconque. Si c'est un listMonType*, le programme segfaulte après ou pendant la suppression du dernier élément. Je recommande de lancer la version deque ainsi : ./test sleep 4 ; kill %+ sans problème chez moi. Est-ce que quelqu'un saurait me dire ce qui se passe, ou au moins me filer des pistes sur la façon de le découvrir ? piste: memtest86! Bon courage! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCb9kHv2w7Uh8v4hcRAsP1AJ9GG12cGM+ovicbtzX1GQBR4UWL8wCcCt8C pcBGwlCsciaYR9eZhLaRgAI= =x7/Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
