What exactly is a POD type

[Matthias]

I searched the standard for an exact explanation of what "plain old
data" might be... I suppose, built-in types are POD. But what about this:

struct Data {
int a,b;
};

Is Data a POD type?

[Andrey Tarasevich]

Post by Matthias
I searched the standard for an exact explanation of what "plain old
struct Data {
int a,b;
};
Is Data a POD type?
...

Yes.

The definition of POD type is given in 3.9/10 and is partially based on
definition of "POD-class" given in 9/4, which is in turn based on the
definition of "aggregate" given in 8.5.1/1.

[fabioppp]

Post by Matthias
struct Data {
int a,b;
};
Is Data a POD type?
...

Yes.

Another question...
Why offsetof macro may not work with non POD types?
And why pointer to members should?

--
fabioppp

[Ron Natalie]

Post by fabioppp
Another question...
Why offsetof macro may not work with non POD types?
And why pointer to members should?

...because the standard says so.

Poitner to members aren't just an offset by the way. They
have to work on polymorphic objects and hence need additional
information.

[fabioppp]

Post by Ron Natalie
Poitner to members aren't just an offset by the way. They
have to work on polymorphic objects and hence need additional
information.

The only problem I can figure out is multiple inheritance,
where the offset of a field has to be added with some other value.
With static offset there is no way to achieve this, while pointer to
member (because of the heaviest typing) can achieve this.

[Ron Natalie]

Post by fabioppp

Post by Ron Natalie
Poitner to members aren't just an offset by the way. They
have to work on polymorphic objects and hence need additional
information.

The only problem I can figure out is multiple inheritance,
where the offset of a field has to be added with some other value.
With static offset there is no way to achieve this, while pointer to
member (because of the heaviest typing) can achieve this.

In practice, that is the problem (virutal inheritance adds yet another
wrinkle).

I believe that at some point in setting down the rules, someone had
the idea that some kind of runtime access control might be useful and
hence put restrictions on things (offsetof, member ordering) that
relax the concept that classes are contiguous accross access specifiers.

[John Carson]

Post by Matthias
I searched the standard for an exact explanation of what "plain old
struct Data {
int a,b;
};
Is Data a POD type?

Yes. See the C++ FAQ:

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

[Matthias]

Post by John Carson

Post by Matthias
I searched the standard for an exact explanation of what "plain old
struct Data {
int a,b;
};
Is Data a POD type?

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

The FAQ mention that POD types must not have constructors or a
destructor. I guess they mean /user defined/ ctor/dtor? Because the Data
struct above has a compiler generated ctor/dtor right? This would by
definition of the FAQ make it a non-POD type.

[Ioannis Vranos]

Post by Matthias
The FAQ mention that POD types must not have constructors or a
destructor. I guess they mean /user defined/ ctor/dtor?

Yes.

[E. Robert Tisdale]

Post by Matthias
I searched the standard for an exact explanation of what "plain old
struct Data {
int a,b;
};
Is Data a POD type?

No.

Plain Old Data refers to built-in data types -- intrgral types:
signed and unsigned char, short int, int, long int, long long int
and floating-point types float, double and long double.

[Andrey Tarasevich]

Post by E. Robert Tisdale
...

Post by Matthias
I searched the standard for an exact explanation of what "plain old
struct Data {
int a,b;
};
Is Data a POD type?

No.
signed and unsigned char, short int, int, long int, long long int
and floating-point types float, double and long double.
...

Wrong. The types you mention are referred to as arithmetic types. All
arithmetic types are POD, but not all POD types are arithmetic.

The above struct is a POD-class, which makes it a POD type.