Hacker News Reader

Comment by bluetomcat | Hacker News Reader

> 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.

View on HN

A 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.

Correct on all accounts. It is definitely not a POD nor a standard layout type (the modern version of POD).

Person has an implicitly generated constructor and destructor which calls std::string's constructor and destructor. It's non-POD.

> 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.

The 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.

I'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).

I 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

POD means you can memcpy without incurring undefined behavior, same as you would in C to copy a struct.

you are probably confusing POD with aggregate.

Reply on news.ycombinator.com