By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,227 Members | 1,290 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,227 IT Pros & Developers. It's quick & easy.

What exactly is a POD type

P: n/a
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
Jul 23 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
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

Jul 23 '05 #2

P: n/a
"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
Jul 23 '05 #3

P: n/a
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
Jul 23 '05 #4

P: n/a
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
Jul 23 '05 #5

P: n/a
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
Jul 23 '05 #6

P: n/a
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.
Jul 23 '05 #7

P: n/a
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.

Jul 23 '05 #8

P: n/a
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

Jul 23 '05 #9

P: n/a
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.

Jul 23 '05 #10

P: n/a
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.
Jul 23 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.