2

What is the difference between the two forms of initialization, T obj = {…} and T obj{…}?
I initially thought T obj = {…} was shorthand for T obj = T{…} where a temporary object is copied into our new object. This, although doesn't execute a copy constructor (copy elision), requires its existence and access to it. But when I blocked copy constructor access in this particular class by making the constructor private, there was no error.
This means that there is no copy mechanism involved. So what's the function of the '=' symbol?
I have referred to the following question but was dissatisfied because of the absence of an explanation:
Is C++11 Uniform Initialization a replacement for the old style syntax?

EDIT: On a similar note, is there a difference between int arr[]{…} and int arr[] = {…}? I am asking this to see if I can bring out the contrast between uniform initialization and list initialization.

Enlico
  • 23,259
  • 6
  • 48
  • 102
Vishal Subramanyam
  • 499
  • 4
  • 19
  • Which standard are you using? C++17 elision could explain your results. Though also note that the `=` in initialisers is often misleading. There is more than one existing question on this topic; your book also should go over this topic. – Asteroids With Wings Mar 22 '20 at 21:56
  • @AsteroidsWithWings, I am using C++17. Even with elision, the only thing that happens is that the copy constructor isn't called. But its existence and access to it is required. If I define a copy constructor and hide it in the class, am I not basically telling the compiler that the copy operation isn't supported? – Vishal Subramanyam Mar 22 '20 at 22:02
  • It uses default and then implicitly generated move constructor. – Александр Кушниренко Mar 22 '20 at 22:06
  • @АлександрКушниренко, so what's the difference between the two statements I've written? – Vishal Subramanyam Mar 22 '20 at 22:07
  • @АлександрКушниренко Is T obj = {...} shorthand for T obj = T{...}? – Vishal Subramanyam Mar 22 '20 at 22:08
  • I've just written code snippet and it calls default constructor anyway, so I was wrong. Maybe the compiler uses some optimization techniques on this matter. – Александр Кушниренко Mar 22 '20 at 22:09
  • @АлександрКушниренко, I have switched off all optimizations in Visual Studio 2017 knowing that this might be a reason. This still happens. – Vishal Subramanyam Mar 22 '20 at 22:10
  • @Vishal Subramanyam, T obj = T{...} doesn't call move constructor too, so I'm confused. – Александр Кушниренко Mar 22 '20 at 22:11
  • Does this answer your question: https://stackoverflow.com/questions/13461027/why-does-the-standard-differentiate-between-direct-list-initialization-and-copy – M.M Mar 22 '20 at 23:01
  • The "edit 2" was a different question, please stick to 1 question per Question. I have rolled back the edit. If you can't answer that question by searching other initialization questions on this site, then post a new question – M.M Mar 22 '20 at 23:10
  • "uniform initialization" is not terminology used by the Standard – M.M Mar 22 '20 at 23:14
  • _"I am using C++17. Even with elision, the only thing that happens is that the copy constructor isn't called. But its existence and access to it is required"_ This is incorrect. You're thinking of the old "optimisation" permitted by previous standards. – Asteroids With Wings Mar 23 '20 at 10:29
  • @АлександрКушниренко _"It uses default and then implicitly generated move constructor."_ That is incorrect. – Asteroids With Wings Mar 23 '20 at 10:31

2 Answers2

2

These have almost exactly the same effect:

  • T x = { 1, 2, 3 };
  • T x { 1, 2, 3 };

Technically the version with = is called copy-list-initialization and the other version is direct-list-initialization but the behaviour of both of those forms is specified by the list-initialization behaviour.

The differences are:

  • If copy-list-initialization selects an explicit constructor then the code is ill-formed.
  • If T is auto, then:
    • copy-list-initialization deduces std::initializer_list<Type_of_element>
    • direct-list-initialization only allows a single element in the list, and deduces Type_of_element.

More information: Why does the standard differentiate between direct-list-initialization and copy-list-initialization?

If T is an array type then the above still applies; since array list initialization is always aggregate initialization, there is never a constructor selected and so the two versions are the same in all cases.

T obj = T{...} (excluding auto) is exactly the same as T obj{...}, since C++17, i.e. direct-list-initialization of obj. Prior to C++17 there was direct-list-initialization of a temporary, and then copy-initialization of obj from the temporary.

M.M
  • 138,810
  • 21
  • 208
  • 365
2

I think that comparing these two syntaxes is not your real question.

It seems to me that you are expecting C++17 elision to behave as did the pre-C++17 "optimisation" permitted by the standard and performed by many implementations.

In that "optimisation", though a copy constructor invocation could be elided, it had to be valid and accessible.

That is not the case with C++17 elision.

This is a true elision, whereby just writing T{} doesn't really create a T, but instead says "I want a T", and an actual temporary is "materialised" only if/when it needs to be.

Redundant utterances of this fact are effectively collapsed into one, so despite screaming "I want a T! I want a T! I want a T! I want a T!" the child still only gets one T in the end.

So, in C++17, T obj = T{...} is literally equivalent to T obj{...}.

That explains the results you're seeing, and your confusion.

You may read more about this feature on cppreference.com; here's a snippet from the top of the page:

Mandatory elision of copy/move operations

Under the following circumstances, the compilers are required to omit the copy and move construction of class objects, even if the copy/move constructor and the destructor have observable side-effects. The objects are constructed directly into the storage where they would otherwise be copied/moved to. The copy/move constructors need not be present or accessible:

  • [..]
  • In the initialization of an object, when the initializer expression is a prvalue of the same class type (ignoring cv-qualification) as the variable type [..]
Asteroids With Wings
  • 17,071
  • 2
  • 21
  • 35
  • Also, assuming T is a class with a constructor that has parameters, `T obj = {param1, param2}` works by invoking the correct constructor. But `T obj = (param1, param2)` doesn't work. Why is that? I did have a confusion regarding elision but your answer clarified that. Is there any resource that explains these language constructs in details? – Vishal Subramanyam Mar 23 '20 at 13:56
  • _"But T obj = (param1, param2) doesn't work. Why is that?"_ Because this is not an initialisation syntax supported by C++. Detailed resource: http://eel.is/c++draft – Asteroids With Wings Mar 23 '20 at 17:59