copy initialization

[Stefan Ram]

IIRC, this is direct initialization:

::std::string s{ "abc" };

; this is copy initialization:

::std::string s = "abc";

. So, it seems that only with the equals sign one gets copy
initialization.

Now, I am looking at this:

::std::string abc{ "abc" };
::std::string s{ abc };

. In the second line »::std::string s{ abc };«, this string
»abc« seems to be /copied/ into the string s. Is it still
correct to say that this is not copy initialization, even
though it involves a copy, because there is no equals sign
in it?

 

[Victor Bazarov]

IIRC, this is direct initialization:

::std::string s{ "abc" };

; this is copy initialization:

::std::string s = "abc";

. So, it seems that only with the equals sign one gets copy
initialization.

Now, I am looking at this:

::std::string abc{ "abc" };
::std::string s{ abc };

. In the second line »::std::string s{ abc };«, this string
»abc« seems to be /copied/ into the string s. Is it still
correct to say that this is not copy initialization, even
though it involves a copy, because there is no equals sign
in it?

I think the difference is in what constructor is used. In the latter
case the copy constructor is used, so, yes, you can call it
copy-initialization.

With the equal sign the construction is *technically* two-stage: first a
temporary is constructed from the literal and then the object is
initialized from that temporary using a copy constructor. The compiler
is allowed to skip the second step and construct the 's' object
directly, of course, but that's not how it happens *semantically*.

To muddy the waters further, built-in types are directly initialized
even in the presence of the equal sign. IOW

int a{42};

and

int a = 42;

are the same. The difference only comes with user-defined types, and
std::string is such a type.

V

 

[Stefan Ram]

I think the difference is in what constructor is used. In the latter
case the copy constructor is used, so, yes, you can call it
copy-initialization.

I am confused, because n3797 says in 8.5p15 and 8.5p16:

|The initialization that occurs in the form
|T x = a;
|as well as in argument passing, function return, throwing an
|exception (15.1), handling an exception (15.3), and aggregate
|member initialization (8.5.1) is called copy-initialization.

|The initialization that occurs in the forms
|T x(a);
|T x{a};
|as well as in new expressions (5.3.4), static_cast expressions
|(5.2.9), functional notation type conversions (5.2.3), and
|base and member initializers (12.6.2) is called direct-initialization.

, which seems to give no reason to call »::std::string s{ abc };«
»copy-initialization« under any circumstances.

 

[Victor Bazarov]

I am confused, because n3797 says in 8.5p15 and 8.5p16:

|The initialization that occurs in the form
|T x = a;
|as well as in argument passing, function return, throwing an
|exception (15.1), handling an exception (15.3), and aggregate
|member initialization (8.5.1) is called copy-initialization.

|The initialization that occurs in the forms
|T x(a);
|T x{a};
|as well as in new expressions (5.3.4), static_cast expressions
|(5.2.9), functional notation type conversions (5.2.3), and
|base and member initializers (12.6.2) is called direct-initialization.

, which seems to give no reason to call »::std::string s{ abc };«
»copy-initialization« under any circumstances.

<shrug> IMHO, any initialization that involves a copy constructor is
copy-initialization. The second sub-bullet in the sixth bullet in
8.5/16 speaks about "the remaining copy-initialization cases", and in it
you can find that the temporary is used to "direct-initialize" the
object. Now, is that a copy-initialization or direct initialization?
Do you *really* need to make a distinction here? The case of s{abc} is
a direct initialization that is accomplished by invoking a copy
constructor. Whether you want to call it copy-initialization or explain
the difference it in so many words, is up to you, I guess.

What is more important to you, to explain how it works or to use the
correct terminology (if, like here, those are at odds)?

V