Constucteur et initialisation

Constucteur et initialisation - C++ - Programmation

Marsh Posté le 24-11-2006 à 16:14:08    

hello.
 
J'aimerais savoir si il y a une différence entre ses 2 morceau de code:

Code :
  1. class B
  2. {
  3. public:
  4.  B(void) : var(1){}
  5. private:
  6.  int var;
  7. };


 

Code :
  1. class B
  2. {
  3. public:
  4.  B(void){var=1;}
  5. private:
  6.  int var;
  7. };


 
merci d'avance

Reply

Marsh Posté le 24-11-2006 à 16:14:08   

Reply

Marsh Posté le 24-11-2006 à 16:22:20    

non, je crois que c'est pareil dans le premier cas tu utilise une liste d'initialisation et dans le deuxième tu le fait dans le constructeur. Sachant qu'il y a des cas : initialisation de reférence où tu ne peut faire l'initialisation que par la liste d'initialisation...


Message édité par Amonchakai le 24-11-2006 à 16:22:57
Reply

Marsh Posté le 24-11-2006 à 16:33:53    

utilise l'intialisation chaque fois que tu le peux, sinon les membres sont construits avec leur constructeur par défaut ce qui demande du travail inutile
 
string s;
MaClasse()
{
  this->s = "foo";
}
 
ça construit d'abord s comme chaine vide, puis ça doit refaire le boulot pour y affecter "foo" ...

Reply

Marsh Posté le 24-11-2006 à 22:33:58    

+1
même si avec un entier l'optimiseur va applanir tout ça, c'est un bon reflexe à prendre ;)

Reply

Marsh Posté le 24-11-2006 à 23:21:43    

jesus_christ a écrit :

même si avec un entier l'optimiseur va applanir tout ça


Entier ou plus généralement type fondamental, à mon avis, ce n'est pas suffisant. Il faut que le compilateur prouve qu'il n'y a pas d'effet de bord lié à var avant l'affectation dans le bloc.

Reply

Marsh Posté le 25-11-2006 à 11:03:58    

++fab a écrit :

Entier ou plus généralement type fondamental, à mon avis, ce n'est pas suffisant. Il faut que le compilateur prouve qu'il n'y a pas d'effet de bord lié à var avant l'affectation dans le bloc.


dans son cas prouver ça c'est pas dur...
 
niveau assembleur, au lieu de faire un
sub esp, 4          ; empiler une valeur arbitraire
mov [esp+4], 1   ; mettre cette valeur à 1
 
ça fera un
push 1               ; empiler 1
 
la résolution des dépendance peut donc se faire directement au niveau assembleur

Reply

Marsh Posté le 25-11-2006 à 11:33:26    

jesus_christ a écrit :

dans son cas prouver ça c'est pas dur...


Dans son cas oui. Le prouver dans un cas plus général non.
 

Code :
  1. #include "bar.hpp" // declaration de bar
  2. struct S
  3. {
  4.     S( int i )
  5.     {
  6.         bar( i_ );
  7.         i_ = i;
  8.     }
  9.     int i_;
  10. };


Si le compilateur ne peut pas prouver que bar est "pure", l'optimisation échouera.
 

Citation :

la résolution des dépendance peut donc se faire directement au niveau assembleur


? (je ne vois pas comment le résultat d'une optimisation peut prouver quoi que ce soit)


Message édité par ++fab le 25-11-2006 à 11:33:43
Reply

Marsh Posté le 25-11-2006 à 11:46:00    

il compile sans prouver quoi que ce soit, puis à la génération d'asm il optimise. C'est assez facile de calculer les dépendances aux niveau ASM (d'ailleurs le CPU le fait lui-même en hard).

Reply

Marsh Posté le 25-11-2006 à 11:48:41    

?

Reply

Marsh Posté le 25-11-2006 à 12:22:30    

à l'optim niveau asm, il transforme
 
sub esp, 4          ; empiler une valeur arbitraire  
mov [esp+4], 1   ; mettre cette valeur à 1  
 
en  
 
push 1               ; empiler 1  
 
ce qui revient, au bas niveau, à transformer "var = 1" en "var(1)"

Reply

Marsh Posté le 25-11-2006 à 12:22:30   

Reply

Marsh Posté le 25-11-2006 à 14:56:59    

S'il n'y a aucune instruction entre l'initialisation et l'affectation, le compilateur  
a l'oportunité d'effectuer l'optimisation à un niveau de représentation plus élévé.


Message édité par ++fab le 25-11-2006 à 14:57:29
Reply

Marsh Posté le 25-11-2006 à 17:57:36    

je suis d'accord mais au pire, il peut le faire au niveau asm

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed