Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

probleme avec le constructeur par copie :-(

13 réponses
Avatar
PasDeSpam
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


merci

3 réponses

1 2
Avatar
Sylvain Togni
Chanclou a écrit :

Je vois un autre intérêt à ce test d'évitement d'auto- affectation,
lorsque l'objet est constitué de nombreuses variables membres, cela
évite une recopie qui prend du temps. Bien que sachant qu'une
affectation est toujours moins coûteuse qu'un test, ce n'est valable
que pour les gros objets.



Même pour les gros objets, la probabilité d'auto-affectation étant
faible, rajouter le cout d'un test à toutes les affectations pour
économiser quelque rares auto-affectations, en moyenne ce n'est
surement pas rentable.

--
Sylvain Togni
Avatar
Chanclou
Sylvain Togni a écrit :
Chanclou a écrit :

Je vois un autre intérêt à ce test d'évitement d'auto- affectation,
lorsque l'objet est constitué de nombreuses variables membres, cela
évite une recopie qui prend du temps. Bien que sachant qu'une
affectation est toujours moins coûteuse qu'un test, ce n'est valable
que pour les gros objets.



Même pour les gros objets, la probabilité d'auto-affectation étant
faible, rajouter le cout d'un test à toutes les affectations pour
économiser quelque rares auto-affectations, en moyenne ce n'est
surement pas rentable.



Pas faux ! Donc on peut dire que ça dépend de la situation.
cas destruction de données (expliqué par James) ou risque important d'auto-affection sur de gros objets => test
autres cas => pas de test
Avatar
Fabien LE LEZ
On Fri, 19 Sep 2008 14:28:14 +0200, Chanclou :

cas destruction de données (expliqué par James) ou risque import
ant d'auto-affection sur de gros objets => test



Non. Le test en question est une optimisation. On ne parle donc pas de
"risque", mais de mesure par un profiler.
1 2