POD class member order

[Mike - EMAIL IGNORED]

In my POD class:

class MyPodClass
{
public:
MyPodClass(MyCtorArgs);
...
private:
short data1;
short data2;
long data3;
};

Can I rely on the order of the data items
being as they appear? Chapter & verse?

Thanks for your help.
Mike.

 

[Victor Bazarov]

In my POD class:

class MyPodClass
{
public:
MyPodClass(MyCtorArgs);
...
private:
short data1;
short data2;
long data3;
};

Can I rely on the order of the data items
being as they appear? Chapter & verse?

You can, only between two different access specifiers. 9.2/12.

V

 

[Rolf Magnus]

In my POD class:

class MyPodClass
{
public:
MyPodClass(MyCtorArgs);
...
private:
short data1;
short data2;
long data3;
};

Can I rely on the order of the data items
being as they appear?

Depending on whether you want to know the answer for a POD class or for your
example (which is definitely not a POD), the answer is either yes or no.

 

[Phlip]

Depending on whether you want to know the answer for a POD class or for
your
example (which is definitely not a POD), the answer is either yes or no.

It look PODdy to me - why it not a POD?

Mike: Yes, it's a POD, and C++ defines the order of data members between
access specifiers ("private:"). Your implementation must define the packing
between and after data members.

Please write simple code that works, and do not memcpy() this data, or the
eqivalent.

 

[Victor Bazarov]

Rolf Magnus wrote:




It look PODdy to me - why it not a POD?

There is no way to know. The "..." can contain a d-tor, a copy c-tor, and
any number of other things that would make it non-POD.

V

 

[Rolf Magnus]

It look PODdy to me - why it not a POD?

See http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.7

Please write simple code that works, and do not memcpy() this data, or the
eqivalent.

Well, if it was a POD class, using memcpy() on it would be safe. That's one
of the reasons why POD classes are defined the way they are.

 

[Gavin Deane]

It look PODdy to me - why it not a POD?

From 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. [...] A POD class is a class
that is either a POD-struct or a POD-union.

Clearly union isn't applicable.

And from 8.5.1/1
An aggregate is an array or a class with no user-declared constructors,
no private or protected non-static data members, no base classes, and
no virtual functions.

The OP's class has a user-declared constructor and private non-static
data so that makes it non-POD.

Gavin Deane

 

[Phlip]

See http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.7

The private made it non-POD.

Why did I hear once that "the order of members is defined between access
specifiers"? Without private POD members, that just means the compiler can
re-order between 'public:' and 'public:'.

Well, if it was a POD class, using memcpy() on it would be safe. That's
one
of the reasons why POD classes are defined the way they are.

Students should be advised against abusing PODs. Don't declare a POD just
because "I have a bunch of bits here and I want them over there, too".
Prefer high-level language features.

 

[Rolf Magnus]

The private made it non-POD.

Yes, and the presence of a user-defined constructor.

Why did I hear once that "the order of members is defined between access
specifiers"?

You're probably thinking of this:

====================================================================
Nonstatic data members of a (non-union) class declared without an
intervening access-specifier are allocated so that later members have
higher addresses within a class object. The order of allocation of
nonstatic data members separated by an access-specifier is unspecified
====================================================================

So the answer to the OP would be "yes" for both a POD and his example class.
The members would indeed be in same order as they appear in the source
code.

Without private POD members, that just means the compiler can
re-order between 'public:' and 'public:'.

Well, that rule isn't specific to PODs. It applies to all classes.

Students should be advised against abusing PODs. Don't declare a POD just
because "I have a bunch of bits here and I want them over there, too".
Prefer high-level language features.

Right. I just wanted to make clear that memcpy is guaranteed to work for POD
types (and only for those).

 

[Phlip]

Nonstatic data members of a (non-union) class declared without an
intervening access-specifier are allocated so that later members have
higher addresses within a class object. The order of allocation of
nonstatic data members separated by an access-specifier is unspecified

What's the purpose of that rule if you should not treat them as a POD?

private:
int a;
int b;
....
assert(&a + 1 == &b); // ?
assert(&a < &b); // ?

The first assertion would seem to imply you can treat them as an array - if
they pack tightly, too.

 

[Rolf Magnus]

What's the purpose of that rule if you should not treat them as a POD?

Good question.

private:
int a;
int b;
...
assert(&a + 1 == &b); // ?
assert(&a < &b); // ?

The first assertion would seem to imply you can treat them as an array -
if they pack tightly, too.

The next sentence after the one I quoted is:

==========================================================================
Implementation alignment requirements might cause two adjacent members not
to be allocated immediately after each other; so might requirements for
space for managing virtual functions (10.3) and virtual base classes
(10.1).
==========================================================================

So the compiler could e.g. choose to put a vtable pointer between a and b if
the class has virtual member functions.
What I have always been wondering about is the alignment. Is it guaranteed
that the alginment of a type is not larger than the type itself? I guess it
is, because otherwise, you couldn't put it in an array. But that would mean
that the first assertion is indeed guaranteed to be true if the class has
no virtual functions or virtual base classes.