RXBitBoard board;
RXPattern* pattern;
RXBitBoard board;
RXPattern* pattern;
RXBitBoard board;
RXPattern* pattern;
On Wed, 17 Sep 2008 18:03:51 +0200, (Bruno Causse):
>RXBitBoard board;
>RXPattern* pattern;
Étant donnés tes constructeur et opérateur de copie, je ne comprends
pas pourquoi tu utilises un pointeur pour pattern.
Il me semble que
RXPattern pattern;
serait bien plus adapté.
On Wed, 17 Sep 2008 18:03:51 +0200, PasDeSpam@free.fr (Bruno Causse):
>RXBitBoard board;
>RXPattern* pattern;
Étant donnés tes constructeur et opérateur de copie, je ne comprends
pas pourquoi tu utilises un pointeur pour pattern.
Il me semble que
RXPattern pattern;
serait bien plus adapté.
On Wed, 17 Sep 2008 18:03:51 +0200, (Bruno Causse):
>RXBitBoard board;
>RXPattern* pattern;
Étant donnés tes constructeur et opérateur de copie, je ne comprends
pas pourquoi tu utilises un pointeur pour pattern.
Il me semble que
RXPattern pattern;
serait bien plus adapté.
vos discutions sont tres "pointues" pour moi.
l'utilisation d'une classe construite par copie (ou par
affectation) pose des problemes dans mon code.
voici la classe :
class RXBBPatterns {
RXBitBoard board;
RXPattern* pattern;
public :
RXBBPatterns();
//constructeur par copie
RXBBPatterns(const RXBBPatterns& src);
RXBBPatterns& operator=(const RXBBPatterns& src);
~RXBBPatterns();
bool (RXBBPatterns::*generate_patterns[64][2])(RXMove& move) const;
void init_generate_patterns();
};
RXBBPatterns::RXBBPatterns(): pattern(new RXPattern()) {
init_generate_patterns();
pattern->set_WHITE_D4();
pattern->set_BLACK_E4();
pattern->set_BLACK_D5();
pattern->set_WHITE_E5();
}
RXBBPatterns::RXBBPatterns(const RXBBPatterns& src) : board(src.board),
pattern(new RXPattern()) {
memcpy(pattern, src.pattern, sizeof(RXPattern));
init_generate_patterns();
}
RXBBPatterns::~RXBBPatterns() {
delete pattern;
}
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
board = src.board;
memcpy(pattern, src.pattern, sizeof(RXPattern));
}
return *this;
}
est ce que les constructeurs et l'operator= sont correctement ecrits?
quand j'utilise le debugeur j'ai ce message:
Roxane(1266,0xb0103000) malloc: *** error for object 0x358680: incorrect
checksum for freed object - object was probably modified after being
freed.
*** set a breakpoint in malloc_error_break to debug
vos discutions sont tres "pointues" pour moi.
l'utilisation d'une classe construite par copie (ou par
affectation) pose des problemes dans mon code.
voici la classe :
class RXBBPatterns {
RXBitBoard board;
RXPattern* pattern;
public :
RXBBPatterns();
//constructeur par copie
RXBBPatterns(const RXBBPatterns& src);
RXBBPatterns& operator=(const RXBBPatterns& src);
~RXBBPatterns();
bool (RXBBPatterns::*generate_patterns[64][2])(RXMove& move) const;
void init_generate_patterns();
};
RXBBPatterns::RXBBPatterns(): pattern(new RXPattern()) {
init_generate_patterns();
pattern->set_WHITE_D4();
pattern->set_BLACK_E4();
pattern->set_BLACK_D5();
pattern->set_WHITE_E5();
}
RXBBPatterns::RXBBPatterns(const RXBBPatterns& src) : board(src.board),
pattern(new RXPattern()) {
memcpy(pattern, src.pattern, sizeof(RXPattern));
init_generate_patterns();
}
RXBBPatterns::~RXBBPatterns() {
delete pattern;
}
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
board = src.board;
memcpy(pattern, src.pattern, sizeof(RXPattern));
}
return *this;
}
est ce que les constructeurs et l'operator= sont correctement ecrits?
quand j'utilise le debugeur j'ai ce message:
Roxane(1266,0xb0103000) malloc: *** error for object 0x358680: incorrect
checksum for freed object - object was probably modified after being
freed.
*** set a breakpoint in malloc_error_break to debug
vos discutions sont tres "pointues" pour moi.
l'utilisation d'une classe construite par copie (ou par
affectation) pose des problemes dans mon code.
voici la classe :
class RXBBPatterns {
RXBitBoard board;
RXPattern* pattern;
public :
RXBBPatterns();
//constructeur par copie
RXBBPatterns(const RXBBPatterns& src);
RXBBPatterns& operator=(const RXBBPatterns& src);
~RXBBPatterns();
bool (RXBBPatterns::*generate_patterns[64][2])(RXMove& move) const;
void init_generate_patterns();
};
RXBBPatterns::RXBBPatterns(): pattern(new RXPattern()) {
init_generate_patterns();
pattern->set_WHITE_D4();
pattern->set_BLACK_E4();
pattern->set_BLACK_D5();
pattern->set_WHITE_E5();
}
RXBBPatterns::RXBBPatterns(const RXBBPatterns& src) : board(src.board),
pattern(new RXPattern()) {
memcpy(pattern, src.pattern, sizeof(RXPattern));
init_generate_patterns();
}
RXBBPatterns::~RXBBPatterns() {
delete pattern;
}
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
board = src.board;
memcpy(pattern, src.pattern, sizeof(RXPattern));
}
return *this;
}
est ce que les constructeurs et l'operator= sont correctement ecrits?
quand j'utilise le debugeur j'ai ce message:
Roxane(1266,0xb0103000) malloc: *** error for object 0x358680: incorrect
checksum for freed object - object was probably modified after being
freed.
*** set a breakpoint in malloc_error_break to debug
On Wed, 17 Sep 2008 18:03:51 +0200, (Bruno Causse):RXBitBoard board;
RXPattern* pattern;
Étant donnés tes constructeur et opérateur de copie, je ne comprends
pas pourquoi tu utilises un pointeur pour pattern.
Il me semble que
RXPattern pattern;
serait bien plus adapté.
On Wed, 17 Sep 2008 18:03:51 +0200, PasDeSpam@free.fr (Bruno Causse):
RXBitBoard board;
RXPattern* pattern;
Étant donnés tes constructeur et opérateur de copie, je ne comprends
pas pourquoi tu utilises un pointeur pour pattern.
Il me semble que
RXPattern pattern;
serait bien plus adapté.
On Wed, 17 Sep 2008 18:03:51 +0200, (Bruno Causse):RXBitBoard board;
RXPattern* pattern;
Étant donnés tes constructeur et opérateur de copie, je ne comprends
pas pourquoi tu utilises un pointeur pour pattern.
Il me semble que
RXPattern pattern;
serait bien plus adapté.
Fabien LE LEZ wrote:
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src)
{
if ( this != &src ) {
board = src.board ;
pattern = src.pattern ;
}
return *this ;
}
Fabien LE LEZ wrote:
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src)
{
if ( this != &src ) {
board = src.board ;
pattern = src.pattern ;
}
return *this ;
}
Fabien LE LEZ wrote:
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src)
{
if ( this != &src ) {
board = src.board ;
pattern = src.pattern ;
}
return *this ;
}
On Sep 17, 9:54 pm, Michel Decima wrote:Fabien LE LEZ wrote:RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src)
{
if ( this != &src ) {
board = src.board ;
pattern = src.pattern ;
Tant que pattern reste un pointeur, il faudrait:
*pattern = *src.pattern ;
Et s'il cesse d'être un pointeur, la version implicite du
compilateur fait l'affaire.
On Sep 17, 9:54 pm, Michel Decima <michel.dec...@wanadoo.fr> wrote:
Fabien LE LEZ wrote:
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src)
{
if ( this != &src ) {
board = src.board ;
pattern = src.pattern ;
Tant que pattern reste un pointeur, il faudrait:
*pattern = *src.pattern ;
Et s'il cesse d'être un pointeur, la version implicite du
compilateur fait l'affaire.
On Sep 17, 9:54 pm, Michel Decima wrote:Fabien LE LEZ wrote:RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src)
{
if ( this != &src ) {
board = src.board ;
pattern = src.pattern ;
Tant que pattern reste un pointeur, il faudrait:
*pattern = *src.pattern ;
Et s'il cesse d'être un pointeur, la version implicite du
compilateur fait l'affaire.
bool (RXBBPatterns::*generate_patterns[64][2])(RXMove& move) const;
Je suppose qu'il y a plus, parce que sinon, je ne vois pas à
quoi vont pointer ces pointeurs. C'est de toute façon un idiome
assez original.
memcpy(pattern, src.pattern, sizeof(RXPattern));
Ici, il faudrait savoir plus sur RXPattern. En général, memcpy
ne marche que sur les POD.
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
pourquoi il le faudrait.)
bool (RXBBPatterns::*generate_patterns[64][2])(RXMove& move) const;
Je suppose qu'il y a plus, parce que sinon, je ne vois pas à
quoi vont pointer ces pointeurs. C'est de toute façon un idiome
assez original.
memcpy(pattern, src.pattern, sizeof(RXPattern));
Ici, il faudrait savoir plus sur RXPattern. En général, memcpy
ne marche que sur les POD.
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
pourquoi il le faudrait.)
bool (RXBBPatterns::*generate_patterns[64][2])(RXMove& move) const;
Je suppose qu'il y a plus, parce que sinon, je ne vois pas à
quoi vont pointer ces pointeurs. C'est de toute façon un idiome
assez original.
memcpy(pattern, src.pattern, sizeof(RXPattern));
Ici, il faudrait savoir plus sur RXPattern. En général, memcpy
ne marche que sur les POD.
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
pourquoi il le faudrait.)
vos discutions sont tres "pointues" pour moi.
vos discutions sont tres "pointues" pour moi.
vos discutions sont tres "pointues" pour moi.
"James Kanze" a écrit dans le message de news:
On Sep 17, 6:03 pm, (Bruno Causse) wrote:
>> RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
>> if(this != &src) {
>À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
>a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
>pourquoi il le faudrait.)
je pensais que c'etait la facon "classique" d'ecrire les
operators =
je precise, mon prog fonctionne depuis plusieurs années sans
probleme.
"James Kanze" <james.ka...@gmail.com> a écrit dans le message de news:
4280973e-0675-4500-99b0-144d47233...@8g2000hse.googlegroups.com...
On Sep 17, 6:03 pm, PasDeS...@free.fr (Bruno Causse) wrote:
>> RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
>> if(this != &src) {
>À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
>a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
>pourquoi il le faudrait.)
je pensais que c'etait la facon "classique" d'ecrire les
operators =
je precise, mon prog fonctionne depuis plusieurs années sans
probleme.
"James Kanze" a écrit dans le message de news:
On Sep 17, 6:03 pm, (Bruno Causse) wrote:
>> RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
>> if(this != &src) {
>À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
>a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
>pourquoi il le faudrait.)
je pensais que c'etait la facon "classique" d'ecrire les
operators =
je precise, mon prog fonctionne depuis plusieurs années sans
probleme.
On Sep 18, 11:18 am, "Bruno Causse" wrote:"James Kanze" a écrit dans le message de news:
On Sep 17, 6:03 pm, (Bruno Causse) wrote:
[...]RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
pourquoi il le faudrait.)je pensais que c'etait la facon "classique" d'ecrire les
operators >
C'était conseillé souvent avant l'introduction des exceptions,
mais pour des raisons précises qui ne s'appliquent pas ici.
Imagine un instant que ton pointeur designait quelque chose dont
la taille était variable. Et que dans l'opérateur d'affectation,
tu voulais faire un delete de l'ancien objet, et une nouvelle
allocation. Si tu écrivais :
delete pointer ;
pointer = new Object( *other.pointer ) ;
, il y avait un problème si other était en fait une réfèrence au
même objet. Une solution souvent proposée alors était le test
pour l'auto-affectation. (Mais s'il ne pose jamais de problème
en soi, il n'est nécessaire que dans ce cas-ci. Donc, pas dans
ton cas, où il n'y a pas de delete.)
Avec l'introduction des exceptions, on s'est aperçu que cette
solution ne marchait pas ; le new peut lever une exception, qui
laisse l'objet dans un drôle d'état, et en suite, quand on en
appel le destructeur... pointer contient toujours la valeur dont
on a fait le delete. La règle incontournable est devenue
d'exécuter tout ce qui pourrait lever une exception avant de
modifier quoique ce soit dans l'objet, avec l'idiome de swap le
moyen plus ou moins préféré pour y arriver. Dans le cas
problèmatique que je viens de présenter, donc, on écrirait :
Object* tmp = new Object( *other.pointer ) ;
delete pointer ;
pointer = tmp ;
ou, avec l'idiome de swap, quelque chose du genre :
MyClass tmp( *other ) ;
std::swap( pointer, tmp.pointer ) ;
// et ainsi de suite sur les autres éléments...
C'est ensuite le destructeur de tmp qui s'occupera de faire les
delete sur les anciennes valeurs. (Note bien que l'idiome du
swap ne fonctionne que si tous les membres supporte un swap
nothrow.)
Ensuite, j'ai remarqué que dans les cas où il *fallait* le test
pour l'auto-affectation (comme dans mon exemple), on n'était
probablement pas exception-safe.je precise, mon prog fonctionne depuis plusieurs années sans
probleme.
Certes. Dans ton cas, le test n'est pas nécessaire. Et même,
selon l'utilisation de l'objet, c'est bien possible que tu n'as
jamais eu une affectation d'un objet à lui-même. Tu es en fait
en train d'appliquer un idiome que tu as vu quelque part sans
réelement savoir pourquoi, ni même si ton code en est concerné.
--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Sep 18, 11:18 am, "Bruno Causse" <bcau...@lepoint.tm.fr> wrote:
"James Kanze" <james.ka...@gmail.com> a écrit dans le message de news:
4280973e-0675-4500-99b0-144d47233...@8g2000hse.googlegroups.com...
On Sep 17, 6:03 pm, PasDeS...@free.fr (Bruno Causse) wrote:
[...]
RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
pourquoi il le faudrait.)
je pensais que c'etait la facon "classique" d'ecrire les
operators >
C'était conseillé souvent avant l'introduction des exceptions,
mais pour des raisons précises qui ne s'appliquent pas ici.
Imagine un instant que ton pointeur designait quelque chose dont
la taille était variable. Et que dans l'opérateur d'affectation,
tu voulais faire un delete de l'ancien objet, et une nouvelle
allocation. Si tu écrivais :
delete pointer ;
pointer = new Object( *other.pointer ) ;
, il y avait un problème si other était en fait une réfèrence au
même objet. Une solution souvent proposée alors était le test
pour l'auto-affectation. (Mais s'il ne pose jamais de problème
en soi, il n'est nécessaire que dans ce cas-ci. Donc, pas dans
ton cas, où il n'y a pas de delete.)
Avec l'introduction des exceptions, on s'est aperçu que cette
solution ne marchait pas ; le new peut lever une exception, qui
laisse l'objet dans un drôle d'état, et en suite, quand on en
appel le destructeur... pointer contient toujours la valeur dont
on a fait le delete. La règle incontournable est devenue
d'exécuter tout ce qui pourrait lever une exception avant de
modifier quoique ce soit dans l'objet, avec l'idiome de swap le
moyen plus ou moins préféré pour y arriver. Dans le cas
problèmatique que je viens de présenter, donc, on écrirait :
Object* tmp = new Object( *other.pointer ) ;
delete pointer ;
pointer = tmp ;
ou, avec l'idiome de swap, quelque chose du genre :
MyClass tmp( *other ) ;
std::swap( pointer, tmp.pointer ) ;
// et ainsi de suite sur les autres éléments...
C'est ensuite le destructeur de tmp qui s'occupera de faire les
delete sur les anciennes valeurs. (Note bien que l'idiome du
swap ne fonctionne que si tous les membres supporte un swap
nothrow.)
Ensuite, j'ai remarqué que dans les cas où il *fallait* le test
pour l'auto-affectation (comme dans mon exemple), on n'était
probablement pas exception-safe.
je precise, mon prog fonctionne depuis plusieurs années sans
probleme.
Certes. Dans ton cas, le test n'est pas nécessaire. Et même,
selon l'utilisation de l'objet, c'est bien possible que tu n'as
jamais eu une affectation d'un objet à lui-même. Tu es en fait
en train d'appliquer un idiome que tu as vu quelque part sans
réelement savoir pourquoi, ni même si ton code en est concerné.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Sep 18, 11:18 am, "Bruno Causse" wrote:"James Kanze" a écrit dans le message de news:
On Sep 17, 6:03 pm, (Bruno Causse) wrote:
[...]RXBBPatterns& RXBBPatterns::operator=(const RXBBPatterns& src) {
if(this != &src) {
À quoi sert ce test ? (Typiquement, s'il le faut, c'est qu'il y
a un problème ailleurs. Mais dans ce cas-ci, je ne vois pas
pourquoi il le faudrait.)je pensais que c'etait la facon "classique" d'ecrire les
operators >
C'était conseillé souvent avant l'introduction des exceptions,
mais pour des raisons précises qui ne s'appliquent pas ici.
Imagine un instant que ton pointeur designait quelque chose dont
la taille était variable. Et que dans l'opérateur d'affectation,
tu voulais faire un delete de l'ancien objet, et une nouvelle
allocation. Si tu écrivais :
delete pointer ;
pointer = new Object( *other.pointer ) ;
, il y avait un problème si other était en fait une réfèrence au
même objet. Une solution souvent proposée alors était le test
pour l'auto-affectation. (Mais s'il ne pose jamais de problème
en soi, il n'est nécessaire que dans ce cas-ci. Donc, pas dans
ton cas, où il n'y a pas de delete.)
Avec l'introduction des exceptions, on s'est aperçu que cette
solution ne marchait pas ; le new peut lever une exception, qui
laisse l'objet dans un drôle d'état, et en suite, quand on en
appel le destructeur... pointer contient toujours la valeur dont
on a fait le delete. La règle incontournable est devenue
d'exécuter tout ce qui pourrait lever une exception avant de
modifier quoique ce soit dans l'objet, avec l'idiome de swap le
moyen plus ou moins préféré pour y arriver. Dans le cas
problèmatique que je viens de présenter, donc, on écrirait :
Object* tmp = new Object( *other.pointer ) ;
delete pointer ;
pointer = tmp ;
ou, avec l'idiome de swap, quelque chose du genre :
MyClass tmp( *other ) ;
std::swap( pointer, tmp.pointer ) ;
// et ainsi de suite sur les autres éléments...
C'est ensuite le destructeur de tmp qui s'occupera de faire les
delete sur les anciennes valeurs. (Note bien que l'idiome du
swap ne fonctionne que si tous les membres supporte un swap
nothrow.)
Ensuite, j'ai remarqué que dans les cas où il *fallait* le test
pour l'auto-affectation (comme dans mon exemple), on n'était
probablement pas exception-safe.je precise, mon prog fonctionne depuis plusieurs années sans
probleme.
Certes. Dans ton cas, le test n'est pas nécessaire. Et même,
selon l'utilisation de l'objet, c'est bien possible que tu n'as
jamais eu une affectation d'un objet à lui-même. Tu es en fait
en train d'appliquer un idiome que tu as vu quelque part sans
réelement savoir pourquoi, ni même si ton code en est concerné.
--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34