Ca fait pas longtemps que j'utilise les containers da la libraire standard
mais sur ma derniere app j'ai pas eu de probleme
La je commence un autre projet et j'ai eu un probleme avec std::string,
quand je depassais une chaine de 16 caracteres ( a priori c'est la taille
allouée par defaut ) ca lancait un bad_alloc automatiquement
j'ai essayé reserve(), pareil, je recupere un bad_alloc sur le reserve
J'ai ensuite essayé reserve() sur un vector, et, meme erreur...
Je ne sais pas du tout ce qui fait ca et ca fait un moment je m'enerve la
dessus, si quelqu'un aurait une petite idée....
Je ne sais pas du tout ce qui fait ca et ca fait un moment je m'enerve la dessus, si quelqu'un aurait une petite idée....
Étrange. Pourrais-tu poster un bout de code minimal reproduisant le problème ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Flzw
Étrange. Pourrais-tu poster un bout de code minimal reproduisant le problème ?
Merci mais en fait j'ai finalement compris.
Le probleme venait j'utilisais une classe que j'ai codé dans une DLL et en fait j'avais décidé de declarer la classe avec juste les fonctions exportées dans le header de mon app (et donc sans les variables)
Ca marchait a la compilation mais comme les 2 classes etaient pas déclarées pareil ca corrompait la stack et faisait foirer tout les appels suivant a new etc.
Je pensais que l'on pouvait declarer la classe avec juste les methodes publiques et que le compilateur se debrouillerait ( et ca allait dans le sens de ce que dit Bjarne dans son livre) mais comme la representation en memoire et forcément pas la meme...
bref je sais pas si je suis tres claire, mais en rajoutant les variables membres de ma classe dans le header pour mon app, ca marche nickel.
Étrange. Pourrais-tu poster un bout de code minimal reproduisant le
problème ?
Merci mais en fait j'ai finalement compris.
Le probleme venait j'utilisais une classe que j'ai codé dans une DLL et en
fait j'avais décidé de declarer la classe avec juste les fonctions exportées
dans le header de mon app (et donc sans les variables)
Ca marchait a la compilation mais comme les 2 classes etaient pas déclarées
pareil ca corrompait la stack et faisait foirer tout les appels suivant a
new etc.
Je pensais que l'on pouvait declarer la classe avec juste les methodes
publiques et que le compilateur se debrouillerait ( et ca allait dans le
sens de ce que dit Bjarne dans son livre) mais comme la representation en
memoire et forcément pas la meme...
bref je sais pas si je suis tres claire, mais en rajoutant les variables
membres de ma classe dans le header pour mon app, ca marche nickel.
Étrange. Pourrais-tu poster un bout de code minimal reproduisant le problème ?
Merci mais en fait j'ai finalement compris.
Le probleme venait j'utilisais une classe que j'ai codé dans une DLL et en fait j'avais décidé de declarer la classe avec juste les fonctions exportées dans le header de mon app (et donc sans les variables)
Ca marchait a la compilation mais comme les 2 classes etaient pas déclarées pareil ca corrompait la stack et faisait foirer tout les appels suivant a new etc.
Je pensais que l'on pouvait declarer la classe avec juste les methodes publiques et que le compilateur se debrouillerait ( et ca allait dans le sens de ce que dit Bjarne dans son livre) mais comme la representation en memoire et forcément pas la meme...
bref je sais pas si je suis tres claire, mais en rajoutant les variables membres de ma classe dans le header pour mon app, ca marche nickel.
drkm
"Flzw" writes:
Le probleme venait j'utilisais une classe que j'ai codé dans une DLL et en fait j'avais décidé de declarer la classe avec juste les fonctions exportées dans le header de mon app (et donc sans les variables)
Ca marchait a la compilation mais comme les 2 classes etaient pas déclarées pareil ca corrompait la stack et faisait foirer tout les appels suivant a new etc.
Ca s'appelle une violation de l'ODR.
Je pensais que l'on pouvait declarer la classe avec juste les methodes publiques et que le compilateur se debrouillerait
Non.
( et ca allait dans le sens de ce que dit Bjarne dans son livre) mais comme la representation en memoire et forcément pas la meme...
bref je sais pas si je suis tres claire, mais en rajoutant les variables membres de ma classe dans le header pour mon app, ca marche nickel.
Si je comprend bien, ta classe est définie dans deux fichiers différents ? C'est très déroutant, et très dangereux. Comme le montre ton exemple, si j'ai bien compris.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
"Flzw" <fl0wnz@wanadoo.fr> writes:
Le probleme venait j'utilisais une classe que j'ai codé dans une DLL
et en fait j'avais décidé de declarer la classe avec juste les
fonctions exportées dans le header de mon app (et donc sans les
variables)
Ca marchait a la compilation mais comme les 2 classes etaient pas
déclarées pareil ca corrompait la stack et faisait foirer tout les
appels suivant a new etc.
Ca s'appelle une violation de l'ODR.
Je pensais que l'on pouvait declarer la classe avec juste les
methodes publiques et que le compilateur se debrouillerait
Non.
( et ca
allait dans le sens de ce que dit Bjarne dans son livre) mais comme
la representation en memoire et forcément pas la meme...
bref je sais pas si je suis tres claire, mais en rajoutant les
variables membres de ma classe dans le header pour mon app, ca
marche nickel.
Si je comprend bien, ta classe est définie dans deux fichiers
différents ? C'est très déroutant, et très dangereux. Comme le
montre ton exemple, si j'ai bien compris.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Le probleme venait j'utilisais une classe que j'ai codé dans une DLL et en fait j'avais décidé de declarer la classe avec juste les fonctions exportées dans le header de mon app (et donc sans les variables)
Ca marchait a la compilation mais comme les 2 classes etaient pas déclarées pareil ca corrompait la stack et faisait foirer tout les appels suivant a new etc.
Ca s'appelle une violation de l'ODR.
Je pensais que l'on pouvait declarer la classe avec juste les methodes publiques et que le compilateur se debrouillerait
Non.
( et ca allait dans le sens de ce que dit Bjarne dans son livre) mais comme la representation en memoire et forcément pas la meme...
bref je sais pas si je suis tres claire, mais en rajoutant les variables membres de ma classe dans le header pour mon app, ca marche nickel.
Si je comprend bien, ta classe est définie dans deux fichiers différents ? C'est très déroutant, et très dangereux. Comme le montre ton exemple, si j'ai bien compris.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Flzw
Si je comprend bien, ta classe est définie dans deux fichiers différents ? C'est très déroutant, et très dangereux. Comme le montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut __declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
A moins qu'il y est une autre facon de faire ?
Si je comprend bien, ta classe est définie dans deux fichiers
différents ? C'est très déroutant, et très dangereux. Comme le
montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut
__declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
Si je comprend bien, ta classe est définie dans deux fichiers différents ? C'est très déroutant, et très dangereux. Comme le montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut __declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
A moins qu'il y est une autre facon de faire ?
Loïc Joly
Flzw wrote:
Si je comprend bien, ta classe est définie dans deux fichiers différents ? C'est très déroutant, et très dangereux. Comme le montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut __declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
A moins qu'il y est une autre facon de faire ?
La manière "classique" est de faire un truc du genre
C'est pas très joli, une macro, mais j'ai pas grand chose de mieux à proposer. Autre avantage : Le jour où on compile sous Linux, il suffit de définir cette macro à rien du tout.
-- Loïc
Flzw wrote:
Si je comprend bien, ta classe est définie dans deux fichiers
différents ? C'est très déroutant, et très dangereux. Comme le
montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut
__declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
A moins qu'il y est une autre facon de faire ?
La manière "classique" est de faire un truc du genre
C'est pas très joli, une macro, mais j'ai pas grand chose de mieux à
proposer.
Autre avantage : Le jour où on compile sous Linux, il suffit de définir
cette macro à rien du tout.
Si je comprend bien, ta classe est définie dans deux fichiers différents ? C'est très déroutant, et très dangereux. Comme le montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut __declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
A moins qu'il y est une autre facon de faire ?
La manière "classique" est de faire un truc du genre
C'est pas très joli, une macro, mais j'ai pas grand chose de mieux à proposer. Autre avantage : Le jour où on compile sous Linux, il suffit de définir cette macro à rien du tout.
-- Loïc
Serge Paccalin
Le lundi 30 août 2004 à 01:41, Flzw a écrit dans fr.comp.lang.c++ :
Si je comprend bien, ta classe est définie dans deux fichiers différents ? C'est très déroutant, et très dangereux. Comme le montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut __declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
A moins qu'il y est une autre facon de faire ?
Avec une macro qui changera de valeur selon le projet qui inclut le fichier .h :
/////////////////////////////////////////// // Autre .cpp "client"
#include "Machin.h"
Machin unMachin;
//...
Par ailleurs, si tu veux masquer tes données membres, documente-toi sur le "pimpl idiom", tu m'en diras des nouvelles.
-- ___________ 2004-08-30 10:24:26 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Le lundi 30 août 2004 à 01:41, Flzw a écrit dans fr.comp.lang.c++ :
Si je comprend bien, ta classe est définie dans deux fichiers
différents ? C'est très déroutant, et très dangereux. Comme le
montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut
__declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
A moins qu'il y est une autre facon de faire ?
Avec une macro qui changera de valeur selon le projet qui inclut le
fichier .h :
///////////////////////////////////////////
// Autre .cpp "client"
#include "Machin.h"
Machin unMachin;
//...
Par ailleurs, si tu veux masquer tes données membres, documente-toi sur
le "pimpl idiom", tu m'en diras des nouvelles.
--
___________ 2004-08-30 10:24:26
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Le lundi 30 août 2004 à 01:41, Flzw a écrit dans fr.comp.lang.c++ :
Si je comprend bien, ta classe est définie dans deux fichiers différents ? C'est très déroutant, et très dangereux. Comme le montre ton exemple, si j'ai bien compris.
Ben je suis bien obligé car je dois rajouter l'attribut __declspec(dllexport)
dans les declarations des fonctions membres de la classe dans la dll.
A moins qu'il y est une autre facon de faire ?
Avec une macro qui changera de valeur selon le projet qui inclut le fichier .h :
/////////////////////////////////////////// // Autre .cpp "client"
#include "Machin.h"
Machin unMachin;
//...
Par ailleurs, si tu veux masquer tes données membres, documente-toi sur le "pimpl idiom", tu m'en diras des nouvelles.
-- ___________ 2004-08-30 10:24:26 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
