Talk:cpp/language/copy constructor

Implicitly-generated copy constructor vs member without destructor

I think the implicitly-generated copy constructor is deleted if any members of the type have inaccessible or deleted destructors. I haven't looked it up in the standard, but empirically it looks like they do: https://godbolt.org/z/9KEvjn3re. Is the convention here to verify in the standard before editing, or just go for it, or? Bsilver8192 (talk) 02:16, 23 February 2022 (PST)

indeed, the spec has it in https://eel.is/c++draft/class.copy.ctor#10.3 "defaulted copy/​move constructor for a class X is defined as deleted if X has ... any potentially constructed subobject of a type with a destructor that is deleted or inaccessible from the defaulted constructor". Even going back to C++11, when it was first spelled out, it was "any direct or virtual base class or non-static data member of a type with a destructor that is deleted or inaccessible from the defaulted constructor". I added the missing words. --Cubbi (talk) 07:31, 23 February 2022 (PST)

Adding explicit

I word should be added about "explicit" copy/move constructor. The "explicit" keyword acts a little differently on copy/move constructor as on conversion constructor.

69.70.111.166 13:40, 7 January 2016 (PST)

cpp/language/explicit may be the better location (it already describes the special case of explicit default constructor). What is the difference, though? The semantics are the same as for any other constructor: copy-initialization ignores it, direct-initialization finds it. --Cubbi (talk) 14:35, 7 January 2016 (PST)

The generation of the implicitly-defined copy constructor is deprecated if T has a user-defined destructor or user-defined copy assignment operator. (since C++11)

Is the generation of implicitly-defined copy constructor true?

The generation of the implicitly-defined copy constructor is deprecated if T has a user-defined destructor or user-defined copy assignment operator. (since C++11)

If it is true, there will be more code to add into interface class to enable derived class generate copy code..

could you give an example of what you're describing? When this deprecated feature is removed from the language (after popular compilers issue warnings, such as this one for a while), code that follows rule of 3 (or zero) will not have to change. --Cubbi (talk) 07:44, 16 March 2016 (PDT)

The section about trivial copy constructors seems mutually exclusive. It says that the copy constructor cannot be user defined, but later it says "A trivial copy constructor is a constructor that creates a bytewise copy of the object representation of the argument, and performs no other action." Could a user-provided copy constructor not create a bytewise copy of the object?

a user-defined copy constructor can behave the same way as a trivial copy constructor, but it wouldn't be classified as "trivial" for std::is_trivially_copy_constructible and other parts of the language where that matters. Perhaps it could be improved to say that why "trivial" is an important word of power. --Cubbi (talk) 08:09, 21 September 2016 (PDT)

When can copy object with std::memmove

The standard 3.9/3 requires the class to be TriviallyCopyable in order to allow copying by std::memmove/memcpy. TriviallyCopyable in the standard at 9/6, requires all copy and move ctors, and assignments and dtor must be trivial (and more requirements).
The article currently says: "Objects with trivial copy constructors can be copied by copying their object representations manually, e.g. with std::memmove".
I think this is incorrect. This seems to require only a trivial copy ctor, or some trivial copy ctors, without regard to move ctors and other requirements of TriviallyCopyable. Note that the corresponding paragraph in the 'move constructor' article is different, and does not claim that.
Now it does seem intuitive that if a class has one such trivial copy operation then memcpy should work, but it's not what the standard says (at least in 3.9/3).--Itaj (talk) 18:49, 5 November 2016 (PDT)

I think the intent of the note was that trivial copy ctor is required (but not necessarily sufficient). Replaced with a link to TriviallyCopyable --Cubbi (talk) 11:23, 7 November 2016 (PST)

Syntax section is misleading

The Syntax section suggests there are 3 ways to declare a copy constructor, all of which require an argument of type "const T&". The intro just above explains there are many more possibilities, but reads as a fineprint in comparison to the fancy formatting. Thus to me the Syntax section seems misleadingly incomplete. --Rustyx (talk) 14:17, 8 August 2020 (PDT)

much like "syntax" in cpp/language/aggregate_initialization and some other cpp/language pages, these are some of the possible syntax examples. I think we haven't made up our collective minds on how to better describe such sections. "Common syntax"? --Cubbi (talk) 10:10, 9 August 2020 (PDT)