tags:

views:

140

answers:

1

Is Demo a POD type in C++03?

struct Demo
{
     private:
       int x;
       int y;
};

C++03, §9p4:

A POD-struct is an aggregate class that has no non-static data members of type 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.

After reading Steve Jessop's post, I believe Demo is a non-POD because the members are private. However the Standard doesn't say anything about the relation between POD types and access modifiers.

In C++0x Demo is POD because §9p9 (n3126) says:

A POD struct is a class that is both a trivial class and a standard-layout class, and has no non-static data members of type non-POD struct, non-POD union (or array of such types).

Demo is trivial1 as well as a standard-layout class so it is a POD. Is my interpretation correct?

1 A trivial class is a class that has a trivial default constructor (12.1) and is trivially copyable. [9p5, n3126]

+11  A: 

In C++03, it's definitely not a POD. According to §9/4, "A POD-struct is an aggregate class ...", and according to §8.5.1/1:

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)."

Under C++0x, at least as of N3090/3092, I believe it is a POD. These require only that all non-static members have the same access, not that the access is necessarily public. This is to fix a problem that I believe I was the first to point out -- in C++98/03, a vacuous access specifier leads to a problem:

struct x { 
    int a;
public:
    int b;
public:
   int c;
};

This fits the requirements of a POD struct -- but the standard still gives permission for the relative positions of b and c to be swapped because of the intervening access specifier. As a result, being a POD struct doesn't provide the layout guarantees that were intended to ensure compatibility with C structs (for the obvious example).

Jerry Coffin
Lol, I just wrote that exact same example at the same time as you.
Potatoswatter
… and I should've RTFM'd, C++0x has pushed C++03 out of my head already :vP . +1
Potatoswatter
Thanks!! How could I miss `§8.5.1/1:`? Anyways my interpretation was correct. `;-)`
Prasoon Saurav
@Potatoswatter: there's one difference between the examples we gave. There's also the requirement that a pointer to a POD struct, suitably converted, points to the first member of the struct -- so the first two members cann't be rearranged, even with an intervening access specifier. The second and third can be though...
Jerry Coffin
@Prasoon: It's often missed. For example see: http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/1f21a3731a645cab/3f68c6bedded3ce5. Note that Francis Glassborrow is (and I believe was at the time) the C++ standard committee's "Principle UK Expert"; I'm pretty sure his initial opinion reflected that of the committee as a whole at the time.
Jerry Coffin
And now I say : "Jerry Coffin is a very smart guy" :-)
Prasoon Saurav
@Prasoon: It may be less "smart" than "argumentative". When "everybody knows" something is true, it's almost automatic that some part of me wants to prove them wrong. I try to keep that tendency under control, but...
Jerry Coffin
@Jerry: he he. :-) Good stuff.
Alf P. Steinbach