4 ms·
> So apparently, move does not prevent generation of a copy, but the empty string instead of expected text “Dave” is very interesting. Apparently, after termina
by bluetomcat 2y ago
> So apparently, move does not prevent generation of a copy, but the empty string instead of expected text “Dave” is very interesting. Apparently, after termination of show after the move, the object is invalidated. This does not affect the Person object, but only the string object.
This is a shallow understanding of C++. It happens because the Person object is a POD type that doesn't define a move constructor, and the compiler creates a default one that calls the move constructors of the members. The string member has a well-defined move constructor, but the primitive uint8_t type doesn't.
- flohofwoe 2y agoA move constructor/operator for POD or primitive types doesn't make any sense in the first place though (also AFAIK an object that contains a std::string - like Person - is definitely not a POD?). Even if Person had a manually provided move-constructor and move-assignment-operator, a move would still perform a flat copy from the source to the destination object.
- gpderetta 2y agoCorrect on all accounts. It is definitely not a POD nor a standard layout type (the modern version of POD).
- mort96 2y agoPerson has an implicitly generated constructor and destructor which calls std::string's constructor and destructor. It's non-POD.
- bluetomcat 2y ago> It's non-POD. For a stricter definition of POD which requires that byte-by-byte copies are possible. More informally, it's a POD because it only defines members and all the constructors and destructors are implicitly generated.
- flohofwoe 2y agoI've never seen this definition of 'POD' tbh, 'Plain Old Data' kinda implies that it behaves the same as a C struct when copying and destructing (e.g. the compiler is able to use a memcpy for copying, and destruction is a no-op - both is not the case when there's an embedded std::string object).
- mort96 2y agoI haven't heard your personal informal definition of POD before. I've only concerned myself with the standard's definition of POD. If you were using a different definition of POD than the standard, you should have specified that. Or better yet, not used the term "POD", since it is widely understood to mean what the standard refers to as "POD". EDIT: It seems I've had a slightly incorrect impression of "POD": what makes 'Person' non-POD isn't that it has an implicitly defined constructor but simply that it contains a non-POD type. The requirements for POD classes[1] includes "has no non-static data members of type non-POD class (or array of such types)". std::string is certainly a non-POD class, which makes discussion about Person's constructors and destructors moot. Not that it changes anything, but I don't wanna spread misinformation. [1] https://en.cppreference.com/w/cpp/language/classes#POD_class https://en.cppreference.com/w/cpp/language/classes#POD_class
- gpderetta 2y agoyou are probably confusing POD with aggregate.
- jcranmer 2y agoThe historical notion of POD is that it's a class type that has no C++ shenanigans going on, and thus works like it does in C. As a result, while there are a few slightly different definitions of POD, all of them share the commonality that having a non-POD member makes the class non-POD; in other words, POD-ness has a recursive quality. It doesn't make a lot of sense to not have this recursive quality to POD-ness, because the fact that C++ shenanigans are involved doesn't go away just because it's implicitly handled for you by the compiler.
- elteto 2y agoPOD means you can memcpy without incurring undefined behavior, same as you would in C to copy a struct.