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
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
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.
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
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
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
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
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.
On Fri, 19 Sep 2008 14:28:14 +0200, Chanclou <bchanclo@irisa.fr>:
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.