Talk:cpp/language/move constructor

KK 03:34, 29 January 2013 (PST)KK What is the difference between "Implicitly-declared move constructor" section and "Deleted implicitly-declared move constructor". Can not we combine those two sections into one section.

the first section lists the conditions when the compiler declares a move constructor (which is the first thing people want to know: when does the compiler generate code?). The second section lists the conditions when the compiler prohibits moving. I feel they are reasonably distinct, although they were of course written simply following the description in the standard and are open for rearrangement. Do keep in mind that all special member function pages would need to rearrange the same way for consistency. --Cubbi 07:19, 29 January 2013 (PST)

I think the current layout is better too. P12 20:45, 29 January 2013 (PST)

My concern is it has some duplicate information. Like "Implicitly-declared move constructor" contains, "there are no user-declared move assignment operators" and "Deleted implicitly-declared move constructor" contains, T has a user-defined move constructor or move assignment operator. And if you remove "no" in former section they can be part of latter section. KK 22:34, 29 January 2013 (PST)KK

Yes, that's true. It is possible to remove "there are no user-declared move assignment operators" from the "implicitly declared" section with no loss of information. However, the rest of information seems to be not duplicate, in particular, the "implicitly deleted" section doesn't talk about destructor, copy ctor and copy assigment operator. What do you think? P12 23:13, 29 January 2013 (PST)

Seconded. KK 00:18, 30 January 2013 (PST)KK

Taking away content from implicitly declared rules would be an error. But you're right about redundancy: in fact, this is a copy-paste slip-up. move-assignment makes copy constructors deleted, and I wrote this following copy ctor page. Will fix --Cubbi 06:11, 30 January 2013 (PST)

Matthias: This part "Forcing a move constructor to be generated by the compiler" is wrong. It only means that the compiler will create a move constructor if possible. For example if one of the member types is not moveable no move constructor will be created. What is possible though is to manually declare a move constructor and then instead of defining it yourself doing a "= default" in the source file. That code would fail to compile if one of the members was not movable.--213.47.40.66 14:06, 29 November 2015 (PST)

[edit] "Move constructor cannot be eligible"

Hey, all,

I was initially very confused by what seems to be a logical contradiction in the stated requirements for a 'Trivial Move Constructor' in that section. Specifically, the page currently states that for a move constructor to be trivial, it 'cannot be eligible'. This doesn't make intuitive sense to me and looking at the TriviallyCopyable requirements, it states one of the requirements for being TriviallyCopyable is for every eligible move constructor to be trivial (which is clearly not possible based on the triviality requirements stated on this page).

Having also looked at the Trivial Copy Constructor and Deleted Implicitly-Declared Copy Constructor requirements on that page, I think that perhaps this apparent contradiction is just a copy-and-paste mistake, and that the 'cannot be eligible' requirement was actually intended to be placed under the Deleted implicitly-declared move constructor section, where it would make much more sense to me. That's where it is on the Copy Constructor page.

The Trivial Move Assignment Operator requirements listed on that page match this Move Constructor page, so perhaps they both share this mistake? I am not an expert in this area so I wanted to suggest this theory rather than changing it directly, in case I have misinterpreted something.

Snoof378 (talk) 16:19, 17 December 2020 (PST)