TITLE: "plain old data"

(Newsgroups: comp.std.c++, 2 Aug 99)


BROWN: brahms@mindspring.com (Stan Brown)

>I'm sorry, I seem to have a mental block in my POD, er head. I've never
>really grasped the POD concept, so I hope you'll forgive what are
>probably some stupid follow-up questions. (I checked Stroustrup3, but
>there are no entries "POD" in the index.)


CLAMAGE: Steve Clamage <clamage@eng.sun.com>

Suppose you have an object type defined in a C++ program, and you'd
like code written in C to have access to it. What types can safely
and portably be shared in C and C++ code? (We implicitly assume
a C compiler compatible with the C++ compiler.)

Certainly you can share the basic data types: integer, floating
point, pointers.

Certainly you cannot share a general C++ class in portable code,
since once you introduce C++ features, you might lose the ability
to express portably the layout of the class in C.

What about a struct or union definition that would also be valid
in C?  We'd like to know that the size and layout of the type would
be the same in C and C++.

So the basic idea behind defining "Plain Old Data" was that you
could portably share objects of that type in C and C++ code.  Part
of being able to share objects is that the definition of copying
such an object in C is equivalent to the C++ definition of copying
the object. If you pass an object to C code, and the C code
makes copies of it (passing or returning by value, for example)
the result better be the same as when C++ code makes copies.

The majority of the C++ committee felt that you should be able to
add some C++ features to a struct or union without altering its
POD status. For example, adding static members should not affect
class size, layout or copy semantics, so a POD object can have
static members.

BROWN:

>Yes, I understand that you can use memcpy on an object that contains an
>ordinary pointer, but in practice you never would because then you'd have
>two pointers pointing to the same object, right?

CLAMAGE:

Irrelevant. The semantics of copying a pointer are the same
using memcpy as using copy-construction or copy-assignment.
Besides, if an object has a designated owner, you can have as
many pointers to it as you like.

BROWN:

>Looked at another way, what kind of object is there that you could *not*
>copy using memcpy?

CLAMAGE:

If we take "could not copy" to mean "could not copy with defined
semantics", the answer is any object having a user-written
copy constructor or copy-assignment operator (taking into
account all of its subobjects).