Talk:cpp/language/default constructor

Surprisingly, this page does not contain strict definition of user-declared and user-provided default constructors. --Mmatrosov (talk) 11:46, 18 November 2016 (PST)

I agree it's worth putting it in, on top (before anything compiler-generated), if only to address what "defined as deleted" and "defaulted on its first declaration" classify as. --Cubbi (talk) 12:01, 18 November 2016 (PST)

Any library types with deleted default constructors?

I came to this page looking for a list, or at least one example, of a standard library type that doesn't have a default constructor. It's surprisingly hard to search for such a thing on cppreference, or on Google. Does anyone know an example? --2601:645:C102:3D70:440E:334B:EB05:88F7 10:49, 10 June 2017 (PDT)

`std::reference_wrapper<int>` and lambda/closure types are two examples of what I was looking for. I suspect there might be better examples. --2601:645:C102:3D70:440E:334B:EB05:88F7 10:55, 10 June 2017 (PDT)

I would say the canonical example of non-default-constructible type is std::lock_guard --Cubbi (talk) 12:27, 10 June 2017 (PDT)

Detached =default constructor

Hello. Today after some thought I tried writing explicit default constructor outside of a class, and I succeded:

struct A {
    A();
}

A::A() = default;

I checked the standard, and in section 11.4.2 it is described that = default can be used as a body in a definition of an explicitly defaulted function, while current version of the page does not provide any hint that it is possible: = default is mentioned only in option 4, that looks like only suitable inside the class.

Of course, this applies to all member functions, constructrors and destructors that can be explicitly defaulted.

Shall I try to reorder the Syntax block to provide a better view? LDVSOFT (talk) 05:08, 5 October 2017 (PDT)

It's worth noting that there is a subtle difference between explicitly defaulting the default constructor in-class and out-of-class: providing it out-of-class makes it user-provided, which means that if your class contains an int member, explicitly defaulting the default constructor in-class will initialize the int member with garbage while providing explicitly defaulting it out-of-class will initialize the int member with ​0​. I don't exactly remember where/how it's stated in the standard, but I remember being bitten by the difference once. It might be worth mentioning somewhere. Morwenn (talk) 05:42, 5 October 2017 (PDT)

I added a mention to the top of this page --Cubbi (talk) 06:23, 5 October 2017 (PDT)

What? I thought neither of them should initialize... Samples https://ideone.com/dcN3uE and https://ideone.com/wjAeNY behave like you're right, but neither GCC 7, GCC 6 or Clang 5 on my Linux laptop initializes variables (have a look: [1]). By the way, valgrid screams like crazy. I will reread the standard, but I feel your assumption is terribly wrong... LDVSOFT (talk) 06:34, 5 October 2017 (PDT)

I found my old question on StackOverflow when I got bit by the problem, with quotes from here and from the standard: https://stackoverflow.com/q/26699720/1364752 Looks like I probably got the behaviours swapped in my mind. I would need to double-check the standard to make sure which is which. It really is uncanny... Morwenn (talk) 07:53, 5 October 2017 (PDT)

The more you know! Well, it's now mentioned on the page, and I have learned something new. Thank you all for the help. LDVSOFT (talk) 09:34, 5 October 2017 (PDT)

Objects with trivial default constructors

"Unlike in C, however, objects with trivial default constructors cannot be created by simply reinterpreting suitably aligned storage, such as memory allocated with std::malloc: placement-new is required to formally introduce a new object and avoid potential undefined behavior."

The standard says otherwise. [basic.life]/1: The lifetime of an object of type T begins when: (1.1) — storage with the proper alignment and size for type T is obtained, and (irrelevant). I'm removing that passage. Feel free to reinstate it, citing your references. 134.191.232.68 23:29, 8 November 2017 (PST)n.m.

To record one of the many references, p0593 --Cubbi (talk) 13:14, 9 November 2017 (PST)

However, cpp/named req/PODType still does mention that an object can be created implicitly. Is that true? Should prolly mention it here or at least "see POD" link. --Itaj (talk) 11:33, 1 April 2018 (PDT)

Dropped the mention from the POD concept page (which is a zombie concept now anyway, since the committee is killing it). --Cubbi (talk) 07:39, 10 April 2018 (PDT)