const string et headers

Le
damien gautherin
Bonsoir à tous,

je me pose quelques questions sur l'utilisation de const avec des objets
string dans un header. Je m'explique:

Je recupere un projet dans lequel un certains nombre de const string
sont declares et definis dans un header qui est ensuite inclus dans un
certains nombre de fichiers c++.

myhead.h
const string my_string="string1";

mymod1.cpp
#include "myhead.h"
.

mymod2.cpp
#include "myhead.h"
.


Si je comprends bien lors de la compilation, chaque *module* incluant le
header concerne possede un objet my_string qui lui est propre.

Maintenant, à l'utilisation il arrive que le contenu de cette variable
soit modifié ( pas intentionellement en tout cas ;-) ) pour l'un des
*module*.
Je vais donc me lancer dans une recherche de depassement de tampon qq
part qui pourrait introduire un ecrasement du contenu initiale de ma
variable, mais avant je voudrais juste avoir confirmation que l'espace
memoire reservé à cette variable dans chaque module ne peux pas se
retrouver alloué dans un autre. Oui je me doute que la réponse à cette
question est non => ya un bug dans ton programme, mais bon le doute
m'assaille ;-)

Merci aux courageux qui auront eu le courage de suivre ces qq ligne ;-)

A+
Damien
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
kanze
Le #717965
damien gautherin news:
je me pose quelques questions sur l'utilisation de const avec des
objets string dans un header. Je m'explique:

Je recupere un projet dans lequel un certains nombre de const string
sont declares et definis dans un header qui est ensuite inclus dans un
certains nombre de fichiers c++.

myhead.h
const string my_string="string1";

mymod1.cpp
#include "myhead.h"
....

mymod2.cpp
#include "myhead.h"
....

Si je comprends bien lors de la compilation, chaque *module* incluant
le header concerne possede un objet my_string qui lui est propre.


Tout à fait. Aussi, chaque instance est construite dynamiquement, dans
un ordre indéfini.

Dans l'ensemble, je n'aime pas cette solution. Ou bien, j'utiliserai une
fonction qui renvoie la chaîne en question (en la construisant la
première fois appelée), ou bien, je me servirais des constantes de
chaîne à la C, tout simplement.

Maintenant, à l'utilisation il arrive que le contenu de cette variable
soit modifié ( pas intentionellement en tout cas ;-) ) pour l'un des
*module*.

Je vais donc me lancer dans une recherche de depassement de tampon
qq part qui pourrait introduire un ecrasement du contenu initiale de
ma variable, mais avant je voudrais juste avoir confirmation que
l'espace memoire reservé à cette variable dans chaque module ne peux
pas se retrouver alloué dans un autre.


Normalement non. Maintenant, si tu as un comportement indéfini ailleurs
dans le programme... Si tu te doutes d'un dépassement de tampon, et
c'est réelement le cas, il faut s'attendre à tout. Si par exemple le tas
se trouve corrompu, c'est possible que new renvoie l'adresse d'une zone
déjà allouée, par exemple.

Oui je me doute que la réponse à cette question est non => ya un bug
dans ton programme, mais bon le doute m'assaille ;-)


Si une chaîne définie const change de valeur, ce ne peut être que suite
à une erreur dans ton programme. Si deux objets de type std::string
partage la même mémoire, en revanche, ne signifie rien ; il y a des
implémentations où c'est le cas. Mais tout en étant légal, ça
m'étonnerait dans le cas où toutes les chaînes ont été construites à
partir des chaînes constantes du compilateur.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

damien gautherin
Le #735938
Normalement non. Maintenant, si tu as un comportement indéfini ailleurs
dans le programme... Si tu te doutes d'un dépassement de tampon, et
c'est réelement le cas, il faut s'attendre à tout. Si par exemple le tas
se trouve corrompu, c'est possible que new renvoie l'adresse d'une zone
déjà allouée, par exemple.


Bon c'est bien ce dont j'etais persuadé....reste plus qu'a me mettre en
quete de la source de ce pb :-)

Damien

BlackGoddess
Le #735931
news:
damien gautherin news:
je me pose quelques questions sur l'utilisation de const avec des
objets string dans un header. Je m'explique:

Je recupere un projet dans lequel un certains nombre de const string
sont declares et definis dans un header qui est ensuite inclus dans un
certains nombre de fichiers c++.

myhead.h
const string my_string="string1";

mymod1.cpp
#include "myhead.h"
....

mymod2.cpp
#include "myhead.h"
....

Si je comprends bien lors de la compilation, chaque *module* incluant
le header concerne possede un objet my_string qui lui est propre.


Tout à fait. Aussi, chaque instance est construite dynamiquement, dans
un ordre indéfini.

Dans l'ensemble, je n'aime pas cette solution. Ou bien, j'utiliserai une
fonction qui renvoie la chaîne en question (en la construisant la
première fois appelée), ou bien, je me servirais des constantes de
chaîne à la C, tout simplement.


on pourrait peut-etre utiliser :

myhead.h
extern const std::string my_string;

mymod1.cpp
#include "myhead.h"
const std::string my_string="string1";
....

mymod2.cpp
#include "myhead.h"
....

Maintenant, à l'utilisation il arrive que le contenu de cette variable
soit modifié ( pas intentionellement en tout cas ;-) ) pour l'un des
*module*.

Je vais donc me lancer dans une recherche de depassement de tampon
qq part qui pourrait introduire un ecrasement du contenu initiale de
ma variable, mais avant je voudrais juste avoir confirmation que
l'espace memoire reservé à cette variable dans chaque module ne peux
pas se retrouver alloué dans un autre.


Normalement non. Maintenant, si tu as un comportement indéfini ailleurs
dans le programme... Si tu te doutes d'un dépassement de tampon, et
c'est réelement le cas, il faut s'attendre à tout. Si par exemple le tas
se trouve corrompu, c'est possible que new renvoie l'adresse d'une zone
déjà allouée, par exemple.

Oui je me doute que la réponse à cette question est non => ya un bug
dans ton programme, mais bon le doute m'assaille ;-)


Si une chaîne définie const change de valeur, ce ne peut être que suite
à une erreur dans ton programme. Si deux objets de type std::string
partage la même mémoire, en revanche, ne signifie rien ; il y a des
implémentations où c'est le cas. Mais tout en étant légal, ça
m'étonnerait dans le cas où toutes les chaînes ont été construites à
partir des chaînes constantes du compilateur.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



kanze
Le #721753
"BlackGoddess" news:
news:
damien gautherin news:
je me pose quelques questions sur l'utilisation de const avec des
objets string dans un header. Je m'explique:

Je recupere un projet dans lequel un certains nombre de const
string sont declares et definis dans un header qui est ensuite
inclus dans un certains nombre de fichiers c++.

myhead.h
const string my_string="string1";

mymod1.cpp
#include "myhead.h"
....

mymod2.cpp
#include "myhead.h"
....

Si je comprends bien lors de la compilation, chaque *module*
incluant le header concerne possede un objet my_string qui lui est
propre.


Tout à fait. Aussi, chaque instance est construite dynamiquement,
dans un ordre indéfini.

Dans l'ensemble, je n'aime pas cette solution. Ou bien, j'utiliserai
une fonction qui renvoie la chaîne en question (en la construisant
la première fois appelée), ou bien, je me servirais des constantes
de chaîne à la C, tout simplement.


on pourrait peut-etre utiliser :

myhead.h
extern const std::string my_string;

mymod1.cpp
#include "myhead.h"
const std::string my_string="string1";
....

mymod2.cpp
#include "myhead.h"
....


Ça dépend du contenu de mymod2.cpp. Si c'est :

#include "myhead.h"

std::string const string2 = my_string + ".hpp" ;

par exemple, il y a un comportement indéfini -- si ça marche ou non
risque de dépendre (d'une façon non documentée et non garantie) de
l'ordre que les modules sont incorporés lors de l'édition des liens.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Publicité
Poster une réponse
Anonyme