John Nagle wrote:
> Walter Bright wrote:
> > C++98 9-4 defines POD:

> > "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. Similarly, a POD-union is an aggregate union
> > 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. A POD class is a
> > class that is either a POD-struct or a POD-union."

>     Can a POD-struct contain a pointer of any type?  Arguably, it
> shouldn't.  A pointer is an object with meaning internal to the
> implementation; it's not plain data.

For some particular meaning of "plain".  In the acronym POD, I
think the "old" is the critical part: POD's are, roughly
speaking, the data types we knew from C -- the opposition was
between "plain old data" and "fancy new data" -- fancy new data
being what C++ added to C.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

kanze wrote:
> John Nagle wrote:
>
>>Walter Bright wrote:
>>
>>>C++98 9-4 defines POD:
>
>
>>>"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. Similarly, a POD-union is an aggregate union
>>>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. A POD class is a
>>>class that is either a POD-struct or a POD-union."
>
>
>>    Can a POD-struct contain a pointer of any type?  Arguably, it
>>shouldn't.  A pointer is an object with meaning internal to the
>>implementation; it's not plain data.
>
>
> For some particular meaning of "plain".  In the acronym POD, I
> think the "old" is the critical part: POD's are, roughly
> speaking, the data types we knew from C -- the opposition was
> between "plain old data" and "fancy new data" -- fancy new data
> being what C++ added to C.

    I understand the legacy issue.  But the real distinction for POD is
independence of the data from the execution context.  That's the 'data' part.
You should be able to write POD structures to a file, or send them to
another process or computer, and still have them be meaningful at
the destination end.  Pointers don't have that property.

    More importantly, placing data of unknown content (from, say, an I/O
operation) into a POD structure should not result in undefined behavior.
Pointers don't have that property.

     John Nagle
     Animats

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
.
> You should be able to write POD structures to a file, or send them to
> another process or computer, and still have them be meaningful at
> the destination end.  Pointers don't have that property.

The concept of POD types certainly wasn't created to describe things
possessing that property.

Off-hand, I don't know of any C++ type that is guaranteed by the
standard to have that property. The C++ standard says almost nothing
about the in-memory representation of data, and it says even less about
the representation of data in files. Therefore, modifying the
definition of POD to capture that property would be quite simple (and
completely pointless): "No C++ type is a POD type".

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:

> But the real distinction for POD is
> independence of the data from the execution context.

Is this assertion based on the standard somehow?

>     More importantly, placing data of unknown content (from, say, an I/O
> operation) into a POD structure should not result in undefined behavior.
> Pointers don't have that property.

Nor does int.  Nor does double, IIRC.  Does any datatype other than
unsigned char actually meet this requirement?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle <nagle@animats.com> writes:

> the real distinction for POD is independence of the data from the
> execution context.

No, that's not the real distinction for POD.  The real distinction is
the one given by the standard.

> That's the data' part.  You should be able to write POD structures
> to a file, or send them to another process or computer, and still
> have them be meaningful at the destination end.  Pointers don't have
> that property.
>
>    More importantly, placing data of unknown content (from, say, an I/O
> operation) into a POD structure should not result in undefined behavior.
> Pointers don't have that property.

You're taking the name "Plain ol' Data" and extrapolating from that
what it "should" mean, but that isn't what it's *meant* to mean.  It's
meant to mean, roughly, "data that can be memcpy'd around without
breaking the type system."

If you want something tighter that means "transmittable over a wire
without breaking the type system," you need a new name.  POD is taken.
If anything, the definition of POD should be loosened, so that more
types that can be reasonably memcpy'd can be legally memcpy'd.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.comeaucomputing.com/csc/faq.html                      ]

David Abrahams wrote:
> John Nagle <nagle@animats.com> writes:
>>   More importantly, placing data of unknown content (from, say, an I/O
>>operation) into a POD structure should not result in undefined behavior.
>>Pointers don't have that property.
>
>
> You're taking the name "Plain ol' Data" and extrapolating from that
> what it "should" mean, but that isn't what it's *meant* to mean.  It's
> meant to mean, roughly, "data that can be memcpy'd around without
> breaking the type system."

By the way, I just realized that in the type system that I suggested in
my "reconciling garbage collection with deterministic finalization"
thread, pointers to deterministic objects are not PODs anymore. They are
much like smart pointers - copying them around implies doing some
reference count increment, which rules memcpy out.


Andrei

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

SeeWebsiteForEmail@erdani.org ("Andrei Alexandrescu (See Website For
Email)") writes:

> David Abrahams wrote:
>> John Nagle <nagle@animats.com> writes:
>>>   More importantly, placing data of unknown content (from, say, an I/O
>>>operation) into a POD structure should not result in undefined behavior.
>>>Pointers don't have that property.
>> You're taking the name "Plain ol' Data" and extrapolating from that
>> what it "should" mean, but that isn't what it's *meant* to mean.  It's
>> meant to mean, roughly, "data that can be memcpy'd around without
>> breaking the type system."
>
> By the way, I just realized that in the type system that I suggested
> in my "reconciling garbage collection with deterministic finalization"
> thread, pointers to deterministic objects are not PODs anymore.

Not sure "anymore" applies.  In C++ today, there are no
"deterministic" types in the sense you mean them (i.e. that get
cleaned up automatically even when dynamically allocated).

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.comeaucomputing.com/csc/faq.html                      ]

C++98 9-4 defines POD:

"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. Similarly, a POD-union
is an aggregate union 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. A POD class is a class that is either a
POD-struct or a POD-union."


Ok, but what about base classes? Is a struct or union a POD type only if
all of its base classes are also POD? Or does the existence of any base
classes preclude it being POD? What if one of the base classes is a
virtual base POD class?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

* Walter Bright:
> C++98 9-4 defines POD:
>
> "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. Similarly, a POD-union
> is an aggregate union 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. A POD class is a class that is either a
> POD-struct or a POD-union."
>
>
> Ok, but what about base classes?

A POD is an aggregate, and    8.5.1 describes aggregate classes
(referenced by the para you quoted).

"An aggregate is an array or a class (clause 9) with no user-declared
constructors (12.1), no private or protected non-static data members
(clause 11), no base classes (clause 10), and no virtual functions
(10.3).", i.e., no base classes.

One consequence of having the aggregate neither-fish-nor-fowl thing is
that you can have an aggregate array of non-aggregate element type, such
as std::string, and initialize it using the curly braces syntax.


> Is a struct or union a POD type only if  all of its base classes are also
> POD?

The question doesn't apply.


> Or does the existence of any base classes preclude it being POD?

Yep.


> What if one of the base classes is a virtual base POD class?

The question doesn't apply.

But I don't know why a single POD base class isn't allowed (and for that
base class, and so on)  --  perhaps it was just to simplify the rules?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Walter Bright wrote:
> C++98 9-4 defines POD:
>
> "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. Similarly, a POD-union
> is an aggregate union 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. A POD class is a class that is either a
> POD-struct or a POD-union."
>
>
> Ok, but what about base classes?

Both POD-structs and POD-unions must be aggregates.  Aggregates cannot
have base classes (8.5.1/1).

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Walter Bright wrote:
> C++98 9-4 defines POD:
>
> "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. Similarly, a POD-union
> is an aggregate union 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. A POD class is a class that is either a
> POD-struct or a POD-union."

    Can a POD-struct contain a pointer of any type?  Arguably, it
shouldn't.  A pointer is an object with meaning internal to the
implementation; it's not plain data.

    John Nagle
    Animats

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> Walter Bright wrote:
>> Ok, but what about base classes?
>
> Both POD-structs and POD-unions must be aggregates.  Aggregates cannot
> have base classes (8.5.1/1).

Thank you, I knew there was something I was missing. Thanks also to Alf
P. Steinbach. This clears it up.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
.
>     Can a POD-struct contain a pointer of any type?  Arguably, it
> shouldn't.  A pointer is an object with meaning internal to the
> implementation; it's not plain data.

"Plain Old Data" is simply a convenient catch-phrase - it isn't the
definition.Whenever you're debating what the definition of a term
should be, it's important to keep in mind how that term is going to be
used. The sole purpose of the term POD is to be used in various
guarantees that the standard makes for POD objects, which it does not
make for non-POD objects. I've put together a fairly comprehensive list
of those guarantees:

1.8 p5: POD's occupy contiguous storage
3.6.2 p1: static POD's "shall be initialized before any dynamic
initialization takes place"
3.8 p5: During the time that memory has been allocated for a POD
object,
but outside it's lifetime, it is NOT undefined behavior to use a
pointer
to that memory
        - to access a non-static data member or call a non-static
          member function
        - as the operand of a static_cast<>
3.8 p6: says similar things to 3.8 p5 about lvalues.
3.9 p2: the contents of a POD object can be copied to a sufficiently
large array of 'char' or 'unsigned char' and back again without
changing
the value of the object
3.9 p3: the contents of a POD can be copied using memcpy() to another
object of the same type; the value of the second object will be the
same
as the value of the first.
5.2.2 p7: a POD object can be passed as one of the variable arguments
of
a function
5.3.15 p15: a new-expression doesn't have to waste time initializing a
POD object of class type.
5.19 p4: the address of a POD member can be an address constant
expression.
5.19 p5: a reference to a POD member can be a reference constant
expression.
6.7 p3: you can jump from a place where a local automatic POD object is
not in scope, to one where it is in scope, so long as that object is
declared without an initializer.
6.7 p4: a local static POD object declared with initializers is
initialized before its block is first entered.
8.5 p5: default initialization of a POD object is zero initialization.
8.5 p9: if no initializer is specified for a POD, no initialization
need
be done.
8.5.1 p14: if a static aggregate POD's initializers are constant
expressions, initialization occurs during the static phase of
initialization.
9.2 p14: "Two POD-struct types are layout-compatible if they have the
same number of members, and corresponding members (in order) have
layout
compatible types"
9.2 p15: Similar statement about POD-unions.
9.2 p16: "If a POD-union contains two or more POD-structs that share a
common initial sequence, and if the POD-union contains one of these
POD-structs, it is permitted to inspect the common initial part of any
of them."
9.2 p17: "A pointer to a POD-struct, suitably converted using a
reinterpret_cast, points to its initial member (of if that member is a
bit-field, then to the unit in which it resides) and vice versa."
21 p1: Only a POD type may be used as the "character" type in the
standard's templated string classes.

Every feature that disqualifies a type from being a POD type should be
a feature that makes it unacceptably difficult, on at least some
platforms, to honor one or more of the above guarantees. Which of those
guarantees becomes problematic for a structure type that contains a
member of pointer type?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

> 9.2 p17: "A pointer to a POD-struct, suitably converted using a
> reinterpret_cast, points to its initial member (of if that member is a
> bit-field, then to the unit in which it resides) and vice versa."


Is the following code okay?:

struct Monkey {
    double j;
    int k;
    char s;
};

int main()
{
    Monkey monkey;

    double* p = reinterpret_cast<double*>(&monkey);

    *p = 5.0;
}


-Tom   s

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Tom   s wrote:
> > 9.2 p17: "A pointer to a POD-struct, suitably converted using a
> > reinterpret_cast, points to its initial member (of if that member is a
> > bit-field, then to the unit in which it resides) and vice versa."
>
> Is the following code okay?:
>
> struct Monkey {
>     double j;
>     int k;
>     char s;
> };
>
> int main()
> {
>     Monkey monkey;
>
>     double* p = reinterpret_cast<double*>(&monkey);
>
>     *p = 5.0;
> }

Yes, that's exactly what 9.2p17 describes.


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]