PODs and const data

[Vladimir Jovic]

Hello,

can POD structures have const data?

Like for example this structure :

struct A
{
int a;
int b;
const float c;
};

Can this structure be considered as a POD structure?

 

[Vladimir Jovic]

Hello,

can POD structures have const data?

Like for example this structure :

struct A
{
int a;
int b;
const float c;
};

Can this structure be considered as a POD structure?

I think I found it : 3.9 / 10 speaks about this.

 

[Alf P. Steinbach]

Hello,

can POD structures have const data?

Like for example this structure :

struct A
{
int a;
int b;
const float c;
};

Can this structure be considered as a POD structure?

By C++98 rules it is a POD structure.

Except recursively that it cannot contain anything non-POD, the only prohibited
kind of data member is a member pointer.

If you introduce anything C++'ish like access regions or constructors or a
destructor or assignment operator or virtual member function, then it's no
longer POD. The detailed rules are in §9/4, which refers back to the definition
of aggregate class in §8.5.1. An example of an aggregate is something that would
have been POD except that it has a non-POD member (like std::string).


Cheers & hth.,

- Alf
(blog at <url: http://alfps.wordpress.com>)

 

[Alf P. Steinbach]

By C++98 rules it is a POD structure.

Except recursively that it cannot contain anything non-POD, the only
prohibited kind of data member is a member pointer.

If you introduce anything C++'ish like access regions or constructors or
a destructor or assignment operator or virtual member function, then
it's no longer POD. The detailed rules are in §9/4, which refers back to
the definition of aggregate class in §8.5.1. An example of an aggregate
is something that would have been POD except that it has a non-POD
member (like std::string).

For a moment there I almost posted an incorrect correction to myself.

Anyway, this must be the *ultimate* sillywarning from Visual C++ (versions 7.1
and 9):

warning C4610: struct 'A' can never be instantiated - user defined
constructor required

Then it goes on to instantiate the class, as it should.



Cheers & hth.,

- Alf
(blog at <url: http://alfps.wordpress.com>)

 

[Öö Tiib]

For a moment there I almost posted an incorrect correction to myself.

Anyway, this must be the *ultimate* sillywarning from Visual C++ (versions 7.1
and 9):

   warning C4610: struct 'A' can never be instantiated - user defined
constructor required

Hehe. Obviously warning generator in that good compiler is written by
some MS department of dumb.

 

[Vladimir Jovic]

For a moment there I almost posted an incorrect correction to myself.

Anyway, this must be the *ultimate* sillywarning from Visual C++
(versions 7.1 and 9):

warning C4610: struct 'A' can never be instantiated - user defined
constructor required

As far as the windows is concerned, as long as you don't see :
http://igrad.files.wordpress.com/2010/03/bsod1.jpg
everything is fine [1]

Then it goes on to instantiate the class, as it should.

#include <iostream>
struct A
{
int a;
int b;
const float c;
};
int main()
{
A a = { 4, 6, 3 };
a.a=4;
a.b=2;

A b;
b.a=4;
b.b=2;

std::cout<<"A : a="<<a.a<<" b="<<a.b<<" c="<<a.c<<std::endl;
std::cout<<"B : a="<<b.a<<" b="<<b.b<<" c="<<b.c<<std::endl;
}

gcc in this example (correctly) complains :
error: structure ‘b’ with uninitialized const members



[1] Warning for windows users : Beware! Possible virus!

 

[Paul Bibbings]

By C++98 rules it is a POD structure.

Except recursively that it cannot contain anything non-POD, the only
prohibited kind of data member is a member pointer.

If you introduce anything C++'ish like access regions or constructors
or a destructor or assignment operator or virtual member function,
then it's no longer POD. The detailed rules are in §9/4, which refers
back to the definition of aggregate class in §8.5.1. An example of an
aggregate is something that would have been POD except that it has a
non-POD member (like std::string).

I'd want to question this, although not assertively (rather, in order to
seek clarification).

By [class] §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."

In [dcl.init.aggr], §8.5.1/2:
"When an aggregate is initialized the initializer can be an
initializer-clause consisting of a brace-enclosed, comma-separated
list of initializers for the members of the aggregate, written in
increasing subscript or member order."

This is certainly the case with struct A here, which can be initialized
with:

A a = { 1, 2. 3.4f };

However, by [dcl.init.aggr], §8.5.1/3:
"An aggregate that is a class can also be initialized with a single
expression that is not enclosed in braces, as described in 8.5."

I believe that such expressions include the forms:

A a;
A a2(a);
A a3 = a2;

Now, struct A here does not have a default constructor (including
default copy constructor), and neither is it possible to form the
default copy assignment operator. For this reason, IIUC, there is no
form in which, considered as an aggregate, it could be "initialized with
a single expression that is not enclosed in braces."

I'm always a little uncertain about the correct interpretation of the
word "can" in such instances (as in §8.5.1/3, quoted above) but, at the
present time, I lean towards it equating to "must be capable of being."
If this is the case, then this seems to rule out struct A being an
aggregate, and thus not a POD either.

C++0x reframes a lot of this section and requires a POD to be trivially
copyable. I haven't studied the details of PODs in C++0x in detail, but
as struct A is non-copyable, this seems to strengthen the idea of struct
A not being a POD further.

As I say, though, I am not wanting to assert this, but presenting it as
an interpretation for discussion.

Regards

Paul Bibbings

 

[Alf P. Steinbach]

By C++98 rules it is a POD structure.

Except recursively that it cannot contain anything non-POD, the only
prohibited kind of data member is a member pointer.

If you introduce anything C++'ish like access regions or constructors
or a destructor or assignment operator or virtual member function,
then it's no longer POD. The detailed rules are in §9/4, which refers
back to the definition of aggregate class in §8.5.1. An example of an
aggregate is something that would have been POD except that it has a
non-POD member (like std::string).

I'd want to question this, although not assertively (rather, in order to
seek clarification).

By [class] §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."

In [dcl.init.aggr], §8.5.1/2:
"When an aggregate is initialized the initializer can be an
initializer-clause consisting of a brace-enclosed, comma-separated
list of initializers for the members of the aggregate, written in
increasing subscript or member order."

This is certainly the case with struct A here, which can be initialized
with:

A a = { 1, 2. 3.4f };

However, by [dcl.init.aggr], §8.5.1/3:
"An aggregate that is a class can also be initialized with a single
expression that is not enclosed in braces, as described in 8.5."

I believe that such expressions include the forms:

A a;
A a2(a);
A a3 = a2;

Now, struct A here does not have a default constructor (including
default copy constructor)

Interesting theory.

, and neither is it possible to form the
default copy assignment operator. For this reason, IIUC, there is no
form in which, considered as an aggregate, it could be "initialized with
a single expression that is not enclosed in braces."

I'm always a little uncertain about the correct interpretation of the
word "can" in such instances (as in §8.5.1/3, quoted above) but, at the
present time, I lean towards it equating to "must be capable of being."
If this is the case, then this seems to rule out struct A being an
aggregate, and thus not a POD either.

C++0x reframes a lot of this section and requires a POD to be trivially
copyable. I haven't studied the details of PODs in C++0x in detail, but
as struct A is non-copyable,

It's very much copyable.

this seems to strengthen the idea of struct
A not being a POD further.
Huh.


As I say, though, I am not wanting to assert this, but presenting it as
an interpretation for discussion.

Well, A has a compiler generated copy constructor, if one is used.


Cheers & hth.,

- Alf

 

[Paul Bibbings]

Interesting theory.

Yes, as interesting as any theory can be that is, in fact, utter
rubbish! Sometimes I just wish that, when my brain takes a holiday, my
mouth would go with it, so that I didn't have to suffer hearing myself
utter such nonsense from time to time.

Regards

Paul Bibbings