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?

--
Regards,
Matthias

[Andrey Tarasevich]

Matthias wrote:

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?
...

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.

--
Best regards,
Andrey Tarasevich

[John Carson]

"Matthias" <no****@digitalraid.com> wrote in message
news:cv*************@news.t-online.com

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?

Yes. See the C++ FAQ:

http://www.parashift.com/c++-faq-lit....html#faq-26.7
--
John Carson

[Matthias]

John Carson wrote:

"Matthias" <no****@digitalraid.com> wrote in message
news:cv*************@news.t-online.com

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?

Yes. See the C++ FAQ:

http://www.parashift.com/c++-faq-lit....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.

--
Regards,
Matthias

[fabioppp]

Andrey Tarasevich wrote:

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

[Ioannis Vranos]

Matthias wrote:

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

Yes.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ron Natalie]

fabioppp wrote:

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.

[E. Robert Tisdale]

Matthias wrote:

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?

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]

E. Robert Tisdale wrote:

...

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?

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

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.

--
Best regards,
Andrey Tarasevich

[fabioppp]

Ron Natalie wrote:

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]

fabioppp wrote:

Ron Natalie wrote:

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.