POD: Succinct and definitive, please
Matthew Wilson
but I'll apologise nonetheless for what is a shameless trawling of the
collective knowledge base.
I'm looking for a simple and succinct definition of POD (and I'm not
finding it in section 3.9!). For what it's worth, the best one gets
immortalised. To qualify, it needs to be no more than two sentences.
(Well, three, if you insist.)
Cheers
Matthew Wilson
STLSoft moderator and C++ monomaniac
mailto:mat...@stlsoft.org
http://www.stlsoft.org
news://news.digitalmars.com/c++.stlsoft
"You can tell a Yorkshireman, but you can't tell him much!" -- Uncle
Michael
-------------------------------------------------------------------------------
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Daniel Albuschat
> I'm looking for a simple and succinct definition of POD
Rough rule of thumb:
Everything that's fine to copy with std::mempcy().
cu, Daniel
--
eat(this); // delicious suicide
llewelly
> I guess if you're reading this, it's got past the moderators - :) -
> but I'll apologise nonetheless for what is a shameless trawling of the
> collective knowledge base.
>
> I'm looking for a simple and succinct definition of POD (and I'm not
> finding it in section 3.9!). For what it's worth, the best one gets
> immortalised. To qualify, it needs to be no more than two sentences.
> (Well, three, if you insist.)
[snip]
The definition is scattered throughout the standard. See 8.5.1/1 and
9/4 as well. The resolution to (review status) DR 383 is also
helpful:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#383
Here's my suggestion:
Fundamental types, enums, pointers, pointers to non-static data
members, and arrays of POD type are POD.
classes, structs, and unions which have no base classes, no
virtual functions, no user-declared constructors, no user-declared
copy-assignment operator, no user-declared destructor, no
non-static private or protected members, and no non-static data
members of reference, non-POD, or array of non-POD type, are POD.
Here's a bulleted list alternative:
- Fundamental types.
- enums.
- Pointers.
- Pointers to non-static data members.
- Arrays of POD type.
- classes, structs, or unions which have no:
- base classes
- virtual functions
- user-declared constructors
- user-declared copy-assignment operator
- user-declared destructor
- non-static private or protected members
- non-static data members of reference, non-POD, or array of
non-POD type
I think the bulleted list alternative is easier read, even though it
is many more sentences in some sense.
Maciej Sobczak
Matthew Wilson wrote:
> I'm looking for a simple and succinct definition of POD
> To qualify, it needs to be no more than two sentences.
Well, it is not standardese, but it works fine for me and allows me to
mentally grasp most of the issues concerning PODs:
"POD is a type that would be valid if compiled as C code."
To be more exact, this also covers:
- pointers to members (also if used in structs, arrays or unions)
- "plain" classes (no constructors, no private or protected non-static
data members, no base classes and no virtuals)
but you should get the idea.
The other useful definition is:
"POD is something that can be copied using memcpy function."
--
Maciej Sobczak
http://www.maciejsobczak.com/
Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/
johnchx
> I'm looking for a simple and succinct definition of POD (and I'm not
> finding it in section 3.9!). For what it's worth, the best one gets
> immortalised. To qualify, it needs to be no more than two sentences.
> (Well, three, if you insist.)
The correct answer (llewelly's) has already been posted, so I'll offer
an alternative that sacrifices correctness to simplicity:
POD: "If it's a valid data type in C, it's POD."
I believe that this rule gives no false positives (i.e. if the rule
says it's POD, then it really is POD), but it does give a false
negative in a couple of situations:
class Foo {
public:
int i;
};
Foo is POD even though it's not valid C (because C doesn't provide the
keyword "class").
Also, the following is POD, but not valid C:
struct Bar {};
(IIRC, C doesn't allow empty structs.)
ka...@gabi-soft.fr
news:<bispoi$t4f$05$2...@news.t-online.com>...
> Matthew Wilson wrote:
> > I'm looking for a simple and succinct definition of POD
> Rough rule of thumb:
> Everything that's fine to copy with std::mempcy().
Which is a circular definition, since the rule for copying something
with memcpy is that it must be a POD.
The rule I use is that if I could write it in C, it's a POD. I don't
think it's 100% exact, but it is close enough, easy to remember, and
linked to the historical reasons behind POD.
--
James Kanze GABI Software mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Richard Smith
> - Fundamental types.
> - enums.
> - Pointers.
> - Pointers to non-static data members.
> - Arrays of POD type.
> - classes, structs, or unions which have no:
> - base classes
> - virtual functions
> - user-declared constructors
> - user-declared copy-assignment operator
> - user-declared destructor
> - non-static private or protected members
> - non-static data members of reference, non-POD, or array of
> non-POD type
I think this last sub-bullet needs to include members of
type pointer to member. Bizarrely, a pointer to member is a
POD-type [3.9/10], but a struct containing a pointer to
member is not a POD-struct [9/4]. Can anyone explain why
this should be the case?
--
Richard Smith
Ben Hutchings
Matthew Wilson wrote:
> I guess if you're reading this, it's got past the moderators - :) -
> but I'll apologise nonetheless for what is a shameless trawling of the
> collective knowledge base.
>
> I'm looking for a simple and succinct definition of POD (and I'm not
> finding it in section 3.9!). For what it's worth, the best one gets
> immortalised. To qualify, it needs to be no more than two sentences.
> (Well, three, if you insist.)
POD (plain old data[1]) types are types whose instances can safely
be copied as arrays of bytes, even if they have not been
initialised[2]. Arithmetic, enumeration, pointer and pointer-to-
member types are all POD types, as are arrays of POD types and
const/volatile-qualified POD types[3]. Class, struct and union
types are POD types if and only if they have no base classes, no
user-declared constructors, copy-assignment operators or
destructor, and no virtual functions; and if all their non-static
data members are public, of POD types other than pointer-to-member
types[4], and not const/volatile-qualified[5].
[1] Footnote 4.
[2] Section 3.9 paragraphs 2-4.
[3] Section 3.9 paragraph 10.
[4] Section 8.5.1 paragraph 1 and section 9 paragraph 4. The ban on
pointer-to-member members strikes me as an odd restriction,
given that pointer-to-member types are themselves POD.
[5] I can't find a reference for this, but I am fairly confident that
it is required.
Well, it's not that succinct, and it has three sentences, but that
seemed to be the clearest way to state the definition accurately.
The footnotes are included for reference only.
llewelly
> Daniel Albuschat <dan...@viming.de> wrote in message
> news:<bispoi$t4f$05$2...@news.t-online.com>...
>> Matthew Wilson wrote:
>
>> > I'm looking for a simple and succinct definition of POD
>
>> Rough rule of thumb:
>> Everything that's fine to copy with std::mempcy().
>
> Which is a circular definition, since the rule for copying something
> with memcpy is that it must be a POD.
>
> The rule I use is that if I could write it in C, it's a POD. I don't
> think it's 100% exact,
It's not, it rules out some things which are POD, such as:
struct is_pod{int i;void foo(){/* ... */}};
and
template<int i> struct a{ int ar[i]};
I don't know if that's much of a problem in practice, however.
> but it is close enough, easy to remember, and
> linked to the historical reasons behind POD.
[snip]
I think if most of your team has a good familiarity with C, that's a
good rule, despite the caveat I mention above. But now there are
plenty who just learn C++, and don't really know 'if I could write
it in C'.
Uwe Schnitker
> stl...@hotmail.com (Matthew Wilson) wrote
>
> > I'm looking for a simple and succinct definition of POD (and I'm not
> > finding it in section 3.9!). For what it's worth, the best one gets
> > immortalised. To qualify, it needs to be no more than two sentences.
> > (Well, three, if you insist.)
>
> The correct answer (llewelly's) has already been posted, so I'll offer
> an alternative that sacrifices correctness to simplicity:
>
> POD: "If it's a valid data type in C, it's POD."
>
> I believe that this rule gives no false positives (i.e. if the rule
> says it's POD, then it really is POD), but it does give a false
> negative in a couple of situations:
You are right.
But a POD can also have member function, provided they are not
virtual. (It cannot have constructors, destructors or a copy
assignment operator.)
llewelly
> llewelly wrote:
>
> > - Fundamental types.
> > - enums.
> > - Pointers.
> > - Pointers to non-static data members.
> > - Arrays of POD type.
> > - classes, structs, or unions which have no:
> > - base classes
> > - virtual functions
> > - user-declared constructors
> > - user-declared copy-assignment operator
> > - user-declared destructor
> > - non-static private or protected members
> > - non-static data members of reference, non-POD, or array of
> > non-POD type
>
> I think this last sub-bullet needs to include members of
> type pointer to member. Bizarrely, a pointer to member is a
> POD-type [3.9/10], but a struct containing a pointer to
> member is not a POD-struct [9/4]. Can anyone explain why
> this should be the case?
There's a DR, and based on the DR's resolution I left out the
prohibition against members of pointer-to-member type. The DR is
part of C++2003, so I felt safe leaving it out.
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#148
Richard Smith
"llewelly" <llewe...@xmission.dot.com> wrote in message
news:86y8x7g...@Zorthluthik.local.bar...
> There's a DR, and based on the DR's resolution I left out the
> prohibition against members of pointer-to-member type. The DR is
> part of C++2003, so I felt safe leaving it out.
>
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#148
Thanks for pointing that out. I'd not noticed this DR before.
--
Richard Smith