Discussion :

[r0d]

Bonjour à tous,

dans cette FAQ, il est écrit que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Fred::Fred() : x_() 
{ 
    x_ = n'importe quoi;
}

Dans ce cas, l'expression n'importe quoi provoque la création d'un objet temporaire

Etant sous-entendu que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Fred::Fred(valeur) : x_(valeur) 
{ 
}

Ne le fait pas.

1ere question:
Les 2 codes suivants sont-ils équivalent (est-ce que ce sera le même code ASM généré):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Fred::Fred() : x_() // avec liste d'initialisation, mais vide
{ 
    x_ = n'importe quoi; // et une affectation
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Fred::Fred() // sans liste d'initialisation
{ 
    x_ = n'importe quoi; // et une affectation 
}

2eme question
Connaissez-vous des cas précis où les 2 codes suivants ne sont pas identiques (pas le même code ASM généré):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Fred::Fred()  // sans liste d'initialisation
{ 
    x_ = n'importe quoi;
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Fred::Fred(valeur) : x_(valeur)    // avec liste d'initialisation
{ 
}

Parce que ça fait un moment que je cherche, avec des types composés et tout, mais à chaque fois l'asm est le même.

[3DArchi]

1ere question:
Les 2 codes suivants sont-ils équivalent (est-ce que ce sera le même code ASM généré):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Fred::Fred() : x_() // avec liste d'initialisation, mais vide
{ 
    x_ = n'importe quoi; // et une affectation
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Fred::Fred() // sans liste d'initialisation
{ 
    x_ = n'importe quoi; // et une affectation 
}

Il y a peut être une subtilité qui m'échappe pour un membre qui ne serait pas un type de base, mais si tu ne spécifie pas x_(), c'est le constructeur par défaut qui est appelé... donc je dirais _x().
Il y a une différence si x_ est un type de base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
struct A
{
   A()
   {}
   int m_i;
};
 
struct B
{
   B()
   :m_i()
   {}
   int m_i;
};
int main()
{
   A a;
   B b;
}

a.m_i est non initialisé alors que b.m_i est initialisé à une valeur par défaut (zéro).

2eme question
Connaissez-vous des cas précis où les 2 codes suivants ne sont pas identiques (pas le même code ASM généré):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Fred::Fred()  // sans liste d'initialisation
{ 
    x_ = n'importe quoi;
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Fred::Fred(valeur) : x_(valeur)    // avec liste d'initialisation
{ 
}

Parce que ça fait un moment que je cherche, avec des types composés et tout, mais à chaque fois l'asm est le même.

x_ supporte la copie mais pas l'affectation : le second marche mais pas le premier.
Si x_ redéfinit l'opérateur = et le constructeur par copie alors tu devrais avoir deux codes différents, non ?

[Arzar]

1ere question:
Les 2 codes suivants sont-ils équivalent (est-ce que ce sera le même code ASM généré):

Oui.
Un appel au constructeur par défaut, puis un appel à l'opérateur=.

2eme question
Connaissez-vous des cas précis où les 2 codes suivants ne sont pas identiques (pas le même code ASM généré):

Dès que le constructeur par défaut ou l'opérateur= est suffisament complexe pour dérouter l'optimiseur. Ce qui peut arriver très vite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 
#include <string>
#include <iostream>
 
struct Human
{
    Human():
    name("John Doe"),
    id(492)
    {
    }
 
    Human(const std::string& name_, int id_):
    name(name_),
    id(id_)
    {
    }
 
    std::string name;
    int id;
};
 
struct B
{
    B(const Human& a):a_(a)
    {
    }
 
    Human a_;
};
 
struct C
{
    C(const Human& a)
    {
        a_ = a;
    }
 
    Human a_;
};
 
int main()
{
    Human a("Name", 5);
 
    B b(a);
    C c(a);
}

J'obtiens l'ASM suivant pour la construction de b avec vs2005 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
B b(a);
004010EF  lea         ecx,[esp+28h] 
004010F3  push        ecx  
004010F4  lea         ecx,[esp+4Ch] 
004010F8  call        dword ptr [__imp_std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> > (402044h)] 
004010FE  mov         edx,dword ptr [esp+44h] 
00401102  mov         dword ptr [esp+64h],edx

Le constructeur est inliné.
alors que pour c :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
C c(a);
00401106  lea         eax,[esp+68h] 
0040110A  push        eax  
0040110B  lea         edi,[esp+2Ch] 
0040110F  mov         byte ptr [esp+9Ch],3 
00401117  call        C::C (401000h) 
0040111C  mov         byte ptr [esp+98h],4

Le constructeur n'est plus inliné et son ASM est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
struct C
{
    C(const Human& a)
00401010  push        0FFFFFFFFh 
00401012  push        offset __ehhandler$??0C@@QAE@ABUHuman@@@Z (401968h) 
00401017  mov         eax,dword ptr fs:[00000000h] 
0040101D  push        eax  
0040101E  push        esi  
0040101F  mov         eax,dword ptr [___security_cookie (403000h)] 
00401024  xor         eax,esp 
00401026  push        eax  
00401027  lea         eax,[esp+8] 
0040102B  mov         dword ptr fs:[00000000h],eax 
00401031  mov         esi,dword ptr [esp+18h] 
00401035  push        offset string "John Doe" (402114h) 
0040103A  mov         ecx,esi 
0040103C  call        dword ptr [__imp_std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> > (402040h)] 
00401042  mov         dword ptr [esi+1Ch],1ECh 
    {
        a_ = a;
00401049  push        edi  
0040104A  mov         ecx,esi 
0040104C  mov         dword ptr [esp+14h],0 
00401054  call        dword ptr [__imp_std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator= (402044h)] 
0040105A  mov         eax,dword ptr [edi+1Ch] 
0040105D  mov         dword ptr [esi+1Ch],eax 
    }

[koala01]

Salut,

La journée fut longue et il se fait tard, donc je vais sans doute répondre à coté, mais, il faut garder en mémoire que, si une liste d'initialisation est vide et qu'il existe un constructeur par défaut (trivial), ce sera celui-là qui sera appelé quoi qu'il advienne

Ce ne peut en effet pas être le constructeur par copie qui sera appelé, parce que... le compilateur n'a aucun moyen de savoir quel argument doit être copié pour créer quel membre (sous entendu, lorsque plusieurs membres sont de type identique ou similaire ).

Qu'il te "suffise" d'annuler l'implémentation du constructeur trivial en déclarant un argument quelconque dans le constructeur du membre pour t'en convaincre: le compilateur te "jettera" sans l'ombre d'un remord

Et cela nous ramène tout droit vers la nécessité de s'interroger sur l'opportunité de laisser un constructeur trivial, sachant que ce que l'on attend des constructeur est... de fournir un objet correctement initialisé.

Bien sur, il y a des cas dans lesquels c'est pleinement justifié, mais dans d'autres, il y a un grand intérêt à... s'abstenir

[Médinoc]

Pour la réponse à la première question, il me semble qu'il y a une subtilité pour le cas des types POD (Plain Old Data).

Si je me souviens bien, les types POD sont initialisés à zéro si leur constructeur par défaut est appelé explicitement, mais restent non-initialisés dans le cas contraire...

[3DArchi]

Pour la réponse à la première question, il me semble qu'il y a une subtilité pour le cas des types POD (Plain Old Data).

Si je me souviens bien, les types POD sont initialisés à zéro si leur constructeur par défaut est appelé explicitement, mais restent non-initialisés dans le cas contraire...

J'ai l'impression que ça s'est perdu dans ma réponse :

Il y a une différence si x_ est un type de base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
struct A
{
   A()
   {}
   int m_i;
};
 
struct B
{
   B()
   :m_i()
   {}
   int m_i;
};
int main()
{
   A a;
   B b;
}

a.m_i est non initialisé alors que b.m_i est initialisé à une valeur par défaut (zéro).

[Arzar]

Woa c'est subtil en effet, je n'avais jamais remarqué ce comportement. J'ai pris l'habitude de toujours initialiser les POD dans un constructeur par défaut comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
S::S():
entier(0),
flottant(0.0f),
double(0.0)
{
}

Mais donc en fait on a droit à ce petit raccourci syntaxique ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
S::S():
entier(),
flottant(),
double()
{
}

Ce comportement est garantit ?

Edit : ça marche aussi avec les tableaux !?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
struct S
{
    S():tab()
    {
    }
 
    int tab[50];
};
 
int main()
{
  S s;
}

vs2005 avertit : "warning C4351: new behavior: elements of array 'S::tab' will be default initialized"

[Goten]

Ben si je fais l'analogie avec le cas des templates :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
template <typename T>
void foo()
{
     T t = T(); // garantie que les types POD seront default-initialisé
}

Alors oui c'est autorisé, puisque une fois le template instancié la syntaxe est là même.

[koala01]

Woa c'est subtil en effet, je n'avais jamais remarqué ce comportement. J'ai pris l'habitude de toujours initialiser les POD dans un constructeur par défaut comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
S::S():
entier(0),
flottant(0.0f),
double(0.0)
{
}

Mais donc en fait on a droit à ce petit raccourci syntaxique ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
S::S():
entier(),
flottant(),
double()
{
}

Ce comportement est garantit ?

Oui...

Edit : ça marche aussi avec les tableaux !?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
struct S
{
    S():tab()
    {
    }
 
    int tab[50];
};
 
int main()
{
  S s;
}

vs2005 avertit : "warning C4351: new behavior: elements of array 'S::tab' will be default initialized"

Re oui, pour autant qu'il s'agisse d'un tableau dont la taille est statique

Autrement, c'est le pointeur sur le premier élémentqui sera zero-initialisé et qui vaudra donc NULL (s'il l'est ).

La zero initialisation apparait déjà dans la norme modifiée lors de TR1... Ce qui ne veut pas dire qu'elle n'apparaisse pas plus tot

[Arzar]

Merci !

[r0d]

Okay, merci pour vos réponses

@Arzar: dans l'asm de ton post, il m'a semblé que ce qu'il sa passe, ce n'est pas que le constructeur de Human est inliné, mais c'est qu'il n'est tout simplement pas appelé. Je me demande si ce n'est pas plus une particularité du compilateur et de sa façon d'optimiser, que d'un comportement conforme à la norme.

[Arzar]

C'est fort possible, je suis une grosse buse en assembleur

J'avais interprété comme ceci (en supprimant tous les push, lea et autres mov intermédiaires et en collapsant toutes les templates pour la lisibilité)

Dans le constructeur de B :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
// B b(a); devient en gros
call   dword ptr [__imp_std::string::string (402044h)]

Il me semble que c'est l'appel au constructeur de string prenant un char*, auquel le compilateur passe la chaine "John Doe" stockée à l'adresse 402044h

Et dans celui de C :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
struct C
{
    C(const Human& a)
    call  dword ptr [__imp_std::string::string(402040h)] 
    {

Avant même de rentrer dans la fonction on fait un appel au constructeur de string prenant un char* en passant "John Doe". C'est ce fameux temporaire crée pour rien si on n'utilise pas liste d'initialisation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
     {
        // a_ = a; devient
        call dword ptr [__imp_std::string::operator= (402044h)] 
    }

Puis on appelle l'opérateur= qui prend un char*, ici la chaine "Name" stockée en 402044h.

C'est pas trop n'importe quoi ?