jackklein@att.net (Jack Klein) wrote:
> <Jack>
Is this supposed to be HTML?

> POD stands for "Plain Old Data".
Yes.

[Snip]
> The term is used many times in the standard but IIRC it is defined
> only in a footnote, and footnotes are not normative.

What POD stands for isn't defined anywhere except in a footnote.
But the standard is very explicit about what a POD is.

Compare this to the keyword "const." The standard specifies the
semantics of this keyword in every detail, and it's obvious to
native English-language speakers that the keyword is an
abbreviation(*) for "constant." But the standard doesn't say so!
It comes close in 5.19/1, where const is described as *ONE OF*
the possible elements of a "constant expression." It comes even
closer in 8.3.1/2, where it refers to a const int as a "constant
integer" -- but this is not made explicit for the general case.
(Besides, 8.3.1/2 is an example, and therefore also non-normative.)

My point is that just because the standard doesn't explain how it
came up with a name, that doesn't mean that the name wasn't defined.

(*) Why is the word "abbreviation" so long?

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7jhak7$9ot$1@pravda.ucr.edu> Tom Payne <thp@hill.cs.ucr.edu> writes:
>Maxwell Sayles <fysx@spots.ab.ca> wrote:
>: What does POD stand for?
>
>As I understand it, the intent is that a C++ data type that is
>(recursively) a C data type is called a Plain Old Data (POD) type and
>is subject to the C layout rules.  Those layout rules are relaxed for
>non-POD types.  I'm not exactly sure how much space or time
>optimization that relaxation enables, however.

If I understand you: It's really neutral on this, just as C is.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 7 Jun 1999 16:36:17 GMT, comeau@panix.com (Greg Comeau) wrote:

>In article <375B4F0E.275FC699@spots.ab.ca> Maxwell Sayles <fysx@spots.ab.ca> writes:
>>What does POD stand for?
>
>Plain Ol' Data. ...
> <snip>

BTW, I have recently noticed that there is a typo in the standard's
definition of POD.

The standard states (9/4)-

"A POD-struct is an aggregate class that has no non-static data
members of type pointer to member, non-POD-struct, non-POD-union (or
array of such types) or reference, and has no user-defined copy
assignment operator and no user-defined destructor."

I believe that the correct wording should be-

"A POD-struct is an aggregate class that has no non-static data
members of type pointer to member, non-POD-struct, non-POD-union (or
array of such types) or reference, and has *no private or protected
members, no base classes, no virtual functions, no constructor,* no
user-defined copy assignment operator and no user-defined destructor."

Otherwise, objects with vptrs and members shifted around because they
are under different access specifiers would be PODs- even though they
are patently not compatible with C structs..

,Brian Parker
(bparker@uq.net.au)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3764e306.1924879@news.uq.net.au>,
  bparker@uq.net.au wrote:
> BTW, I have recently noticed that there is a typo in the standard's
> definition of POD.
>
> The standard states (9/4)-
>
> "A POD-struct is an aggregate class that has no non-static data
> members of type pointer to member, non-POD-struct, non-POD-union (or
> array of such types) or reference, and has no user-defined copy
> assignment operator and no user-defined destructor."
>
> I believe that the correct wording should be-
>
> "A POD-struct is an aggregate class that has no non-static data
> members of type pointer to member, non-POD-struct, non-POD-union (or
> array of such types) or reference, and has *no private or protected
> members, no base classes, no virtual functions, no constructor,* no
> user-defined copy assignment operator and no user-defined destructor."

Your added wording might be clearer, but it is not strictly needed.
Those requirements are the definition of an aggregate (8.5.1p1);
the existing wording in 9p4 only covers the additional constraints
that distinguish a POD from other aggregates.
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 15 Jun 99 06:34:08 GMT, bparker@uq.net.au wrote:
>...
>BTW, I have recently noticed that there is a typo in the standard's
>definition of POD.
>
>The standard states (9/4)-
>
>"A POD-struct is an aggregate class that has no non-static data
>members of type pointer to member, non-POD-struct, non-POD-union (or
>array of such types) or reference, and has no user-defined copy
>assignment operator and no user-defined destructor."
>
>I believe that the correct wording should be-
>
>"A POD-struct is an aggregate class that has no non-static data
>members of type pointer to member, non-POD-struct, non-POD-union (or
>array of such types) or reference, and has *no private or protected
>members, no base classes, no virtual functions, no constructor,* no
>user-defined copy assignment operator and no user-defined destructor."
>...

Actually, just after I posted this I reread sec. 9/4 and I see that,
just before the quoted sentence, "aggregate" is in fact defined in
sec. 8.5.1 such that it adds the "no private or protected
members, no base classes, no virtual functions, no constructor"
requirements.
Oh well.... thanks in advance to all who point this out.

,Brian Parker
(bparker@uq.net.au)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3764e306.1924879@news.uq.net.au> bparker@uq.net.au writes:
>The standard states (9/4)- "A POD-struct is an aggregate class....

The use of the word aggregate here is not gratuitous in the sense that
it is used in the English Dictionary sense of the word.  An aggregate
is something specific.  Look at the note just before the above quoted
sentence.  The use of the word aggregate throws many people IMO.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7jpflp$i5$1@pravda.ucr.edu> Tom Payne <thp@hill.cs.ucr.edu> writes:
>Greg Comeau <comeau@panix.com> wrote:
>: In article <7jm1dd$har$1@pravda.ucr.edu> Tom Payne <thp@hill.cs.ucr.edu> writes:
>:>So the alternative to the POD/nonPOD distinction would be to extend
>:>the C layout rules to all C++ class and struct types, which would
>:>require specifying where the various member-function pointers go and
>:>under what conditions, if any, they could be optimized away.
>[...]
>: this is not an alternative.  Said distinction is exactly
>: what POD/nonPOD do.
>
>I thought the POD/nonPOD distinction was introduced to SUSPEND the
>C layout rules for all types except those where C compatibility is
>involved, and that extending C's layout rules to those types
>was an alternative that was rejected for various reasons, e.g.:
>  * possibilities for optimization,
>  * economy of specification (don't specify things that don't matter),
>  * incompatibility with other specifications of C++.

I'd have to check the words to be sure, but it's my understanding that
a POD-struct has alignment and padding allowances which don't intend to
extend the C layout rules.  A non-POD has additional implementation-defined
allowances which do intend to extend the C layout rules.  I think I see
now that your point was that the latter would be spelled out in more detail
instead of just implementation-defined.  Either way their is an extension
though (which is why I said the distinction is what POD/nonPOD do).
Anyway, I think the Standard not spelling it out is the right thing to do.
If it did, it certainly would have constrained things.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7jjjbu$pgi$1@engnews1.eng.sun.com>,
  clamage@eng.sun.com (Steve Clamage) wrote:
> jackklein@att.net (Jack Klein) writes:
> >The term is used many times in the standard but IIRC it is defined
> >only in a footnote, and footnotes are not normative.
>
> The term is completely defined in normative text in clause 9
> paragraph 4, with a reference to section 8.5.1.

That's only the definition of POD-struct and POD-union; POD types
also include scalar types (3.9p10).  (Interesting to note that a
pointer-to-member is a POD type that cannot be a non-static member
of a POD-struct or POD-union.)

The acronym is explained in footnote 4, 1.8p5, but the definition
of the term is normative (albeit distributed).

--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:

: Tom Payne wrote:
:>
:> Maxwell Sayles <fysx@spots.ab.ca> wrote:
:> : What does POD stand for?
:>
:> As I understand it, the intent is that a C++ data type that is
:> (recursively) a C data type is called a Plain Old Data (POD) type and
:> is subject to the C layout rules.  Those layout rules are relaxed for
:> non-POD types.  I'm not exactly sure how much space or time
:> optimization that relaxation enables, however.

: Well, the main reason is not saving of space, but adding extra
: members for special purposes (esp. the vptr).

: However, there are some obvious possible savings from the fact
: that some reordering is allowed:
[...]
: In non-PODs, only the part between two access specifiers has the
: restriction of ascending addresses; therefore this struct may be
: layed out as abcdiiii with no padding and sizeof(NonPOD)==8.

So the alternative to the POD/nonPOD distinction would be to extend
the C layout rules to all C++ class and struct types, which would
require specifying where the various member-function pointers go and
under what conditions, if any, they could be optimized away.  Perhaps
that approach generates even greater tedium.  (It wouldn't, however,
seem as mysterious and capricious as the POD/nonPOD distinction.)

Tom Payne
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <375E2D16.A2B88F6@physik.tu-muenchen.de> Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
>Greg Comeau wrote:
>> In article <375BE6CD.230C02F3@physik.tu-muenchen.de> Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
>> >[PODs are] not automatically initialized, except if they are static objects.
>>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Not what?  Please elaborate.
>
>Not automatically initialized. That is, if you write
>
>void foo()
>{
>  MyPOD var;
>  // ...
>}
>
>you cannot expect to have defined values in var (there is the
>possibility of "illegal" values, like signaling NaN in float).
>
>Of course, if you initialize them explicitly (f.ex. with
>"MyPOD var = { x, y, z };"), things are different; also,
>static storage duration PODs are automatically initialized
>to zero.

Ok, I though you were saying you couldn't even init them as auto's.

>> >You can think of PODs as just dead data lying around in memory,
>> >instead of full objects which take care for themselves.
>>
>> This might imply to some they are unconstructed or something, but the
>> implication should be that they are dead data in the sense of C objects.
>
>In some sense they _are_ unconstructed (unless they are static, or
>explicitly initialized). Default construction (except for static vars
>or explicit "Type()") is a do-nothing,

"In some sense" I agree. :)

>and in addition you can use any valid region of memory

... and properly aligned ....

>as POD without a need to first construct this
>POD there:
>
>POD* pPOD = (POD*)malloc(sizeof(POD));
>*pPod = somePOD; // OK
>
>NonPOD pNonPOD = (NonPOD*)malloc(sizeof(NonPOD);
>*pNonPOD = someNonPOD; // Error: No NonPOD where the pointer points to
>new(pNonPod) NonPOD; // Now construct a NonPOD in the given memory
>*pNonPOD = someNonPOD; // OK: Now we have a NonPOD to assign to.
>
>At least this is how I understand it. If I'm wrong, please
>tell me.

I suspect that we're saying the same thing in different ways.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7jm1dd$har$1@pravda.ucr.edu> Tom Payne <thp@hill.cs.ucr.edu> writes:
>So the alternative to the POD/nonPOD distinction would be to extend
>the C layout rules to all C++ class and struct types, which would
>require specifying where the various member-function pointers go and
>under what conditions, if any, they could be optimized away.  Perhaps
>that approach generates even greater tedium.  (It wouldn't, however,
>seem as mysterious and capricious as the POD/nonPOD distinction.)

Mysterious and capricious is in the eye of the beholder.

Anyway, this is not an alternative.  Said distinction is exactly
what POD/nonPOD do.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau <comeau@panix.com> wrote:

: In article <7jm1dd$har$1@pravda.ucr.edu> Tom Payne <thp@hill.cs.ucr.edu> writes:
:>So the alternative to the POD/nonPOD distinction would be to extend
:>the C layout rules to all C++ class and struct types, which would
:>require specifying where the various member-function pointers go and
:>under what conditions, if any, they could be optimized away.
[...]
: this is not an alternative.  Said distinction is exactly
: what POD/nonPOD do.

I thought the POD/nonPOD distinction was introduced to SUSPEND the
C layout rules for all types except those where C compatibility is
involved, and that extending C's layout rules to those types
was an alternative that was rejected for various reasons, e.g.:
  * possibilities for optimization,
  * economy of specification (don't specify things that don't matter),
  * incompatibility with other specifications of C++.

Tom Payne
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

What does POD stand for?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <375B4F0E.275FC699@spots.ab.ca> Maxwell Sayles <fysx@spots.ab.ca> writes:
>What does POD stand for?

Plain Ol' Data.  It originally came about as another opportunity for
C++ to have a "fighting chance" at being compatible with C.  In specific,
since C++ implementations are allowed to add things into a C++ class,
among other things, then how could a class ever be binary compatible with
say a C struct?  There needed to be some way to say that a compatible
object memory model was possible.  So you end up with things like POD
class types, POD object type, POD struct types, POD union types, etc
(even a scalar is a POD type) and non-POD version of them too.

BTW, the intent is not necessarily that this needs to be in all cases,
just some.  Something like a class with a virtual function does impose
a virtual function pointer into each object by most implementations.
Such a class would not be a POD.  However, it would be a shame if you
couldn't #include a so-called C header during a C++ compilation and never
have a shot at say a struct being equivalent across C++ & C (and other
languages).  So in those cases there would probably be no additional
overhead or machinery necessary.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Maxwell Sayles wrote:
>
> What does POD stand for?

"Plain Old Data". It basically represents a set of restrictions on C++
types; objects of types that meet those restrictions are simple enough
to be safely exchanged with C code.

Specifically:
Section 3.9 p10: "Scalar types, POD-struct types, POD-union types
(clause 9), arrays of such types and _cv-qualified_ version of these
types (3.9.3) are collectively called _POD types_."

Section 9 p4: "A _POD-struct_ is an aggregate class that has no
non-static data members of type pointer to member, non-POD-struct,
non-POD-union (or array of stuch types) or reference, and has no
user-defined copy assignment operator and no user-defined destructor.
Similarly, a _POD-union_ is an aggregate union that [same description].
A _POD-class_ is a class that is either a POD-struct or a POD-union."


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <375B4F0E.275FC699@spots.ab.ca>, fysx@spots.ab.ca says...
> What does POD stand for?

It stands for "Plain Old Data" -- it's a struct or class that
basically fits the C rules for what you can put into a struct.  It
can't contain virtual member functions, a constructor or destructor,
etc.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Maxwell Sayles wrote:
>
> What does POD stand for?

Plain Old Data.

It's everything which has no base classes, no protected or private
members, no reference members, no constructor, destructor or
assignment operator and no virtual member function. (Did I forget
something?)

The main point about a POD is that you can do all the dirty
things with them you can do in C, like memcpy, not explicitly
constructing/destructing it, etc. Moreover, they are not
automatically initialized, except if they are static objects.

You can think of PODs as just dead data lying around in memory,
instead of full objects which take care for themselves.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <375B4F0E.275FC699@spots.ab.ca>,
  Maxwell Sayles <fysx@spots.ab.ca> wrote:
> What does POD stand for?

ISO/IEC 14882 Programming languages C++
Ch. 1.8 "The C++ object model", footnode 4:
The acronym POD stands for "plain old data."

/Niklas Mellin


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Maxwell Sayles <fysx@spots.ab.ca> wrote:
: What does POD stand for?

As I understand it, the intent is that a C++ data type that is
(recursively) a C data type is called a Plain Old Data (POD) type and
is subject to the C layout rules.  Those layout rules are relaxed for
non-POD types.  I'm not exactly sure how much space or time
optimization that relaxation enables, however.

Tom Payne
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 07 Jun 99 05:12:12 GMT, Maxwell Sayles <fysx@spots.ab.ca> wrote in
comp.std.c++:

> What does POD stand for?

<Jack>

POD stands for "Plain Old Data".  What it means is a struct or class
which contains nothing but simple data items, no member functions.  If
it is a struct or changed from a class to a struct it could compile in
a C program.

The term is used many times in the standard but IIRC it is defined
only in a footnote, and footnotes are not normative.

</Jack>
--
Do not email me with questions about programming.
Post them to the appropriate newsgroup.
Followups to my posts are welcome.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jackklein@att.net (Jack Klein) writes:

>On 07 Jun 99 05:12:12 GMT, Maxwell Sayles <fysx@spots.ab.ca> wrote in
>comp.std.c++:

>> What does POD stand for?

>POD stands for "Plain Old Data".  What it means is a struct or class
>which contains nothing but simple data items, no member functions.  If
>it is a struct or changed from a class to a struct it could compile in
>a C program.

A POD can contain static member functions and private or protected
static data members.

>The term is used many times in the standard but IIRC it is defined
>only in a footnote, and footnotes are not normative.

The term is completely defined in normative text in clause 9
paragraph 4, with a reference to section 8.5.1.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tom Payne wrote:
>
> Maxwell Sayles <fysx@spots.ab.ca> wrote:
> : What does POD stand for?
>
> As I understand it, the intent is that a C++ data type that is
> (recursively) a C data type is called a Plain Old Data (POD) type and
> is subject to the C layout rules.  Those layout rules are relaxed for
> non-POD types.  I'm not exactly sure how much space or time
> optimization that relaxation enables, however.

Well, the main reason is not saving of space, but adding extra
members for special purposes (esp. the vptr).
However, there are some obvious possible savings from the fact
that some reordering is allowed:

Look at this POD:

struct POD
{
  char a;
  int i;
  char b;
  char c;
  char d;
};

Since the POD rules demand ascending addresses, the layout on
a system with 4 byte aligned 4 byte ints looks is a___iiiibcd_
(_ denotes padding) and sizeof(POD)==12.

Now let's make it a non-POD:

struct NonPOD
{
  char a;
  int i;
private: // makes it non-POD
  char b;
  char c;
  char d;
};

In non-PODs, only the part between two access specifiers has the
restriction of ascending addresses; therefore this struct may be
layed out as abcdiiii with no padding and sizeof(NonPOD)==8.

I don't know if any compiler does that, though.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37615842.1212991826@netnews.worldnet.att.net> jackklein@att.net (Jack Klein) writes:
>The term [POD] is used many times in the standard but IIRC it is defined
>only in a footnote, and footnotes are not normative.

That's tending to be misleading.  Yes, what the letters POD stand for are
only in a footnote, but what PODs are or aren't (non-PODs) are clearly
spelled out by the standard.  In specific it discussed POD types, objects,
etc.  There really is no Plain Ol' POD :)

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <375BE6CD.230C02F3@physik.tu-muenchen.de> Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
>[PODs are] not automatically initialized, except if they are static objects.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Not what?  Please elaborate.

>You can think of PODs as just dead data lying around in memory,
>instead of full objects which take care for themselves.

This might imply to some they are unconstructed or something, but the
implication should be that they are dead data in the sense of C objects.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau wrote:
>
> In article <375BE6CD.230C02F3@physik.tu-muenchen.de> Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
> >[PODs are] not automatically initialized, except if they are static objects.
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Not what?  Please elaborate.

Not automatically initialized. That is, if you write

void foo()
{
  MyPOD var;
  // ...
}

you cannot expect to have defined values in var (there is the
possibility of "illegal" values, like signaling NaN in float).

Of course, if you initialize them explicitly (f.ex. with
"MyPOD var = { x, y, z };"), things are different; also,
static storage duration PODs are automatically initialized
to zero.

>
> >You can think of PODs as just dead data lying around in memory,
> >instead of full objects which take care for themselves.
>
> This might imply to some they are unconstructed or something, but the
> implication should be that they are dead data in the sense of C objects.

In some sense they _are_ unconstructed (unless they are static, or
explicitly initialized). Default construction (except for static vars
or explicit "Type()") is a do-nothing, and in addition you can use any
valid region of memory as POD without a need to first construct this
POD there:

POD* pPOD = (POD*)malloc(sizeof(POD));
*pPod = somePOD; // OK

NonPOD pNonPOD = (NonPOD*)malloc(sizeof(NonPOD);
*pNonPOD = someNonPOD; // Error: No NonPOD where the pointer points to
new(pNonPod) NonPOD; // Now construct a NonPOD in the given memory
*pNonPOD = someNonPOD; // OK: Now we have a NonPOD to assign to.

At least this is how I understand it. If I'm wrong, please
tell me.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]