c++0x pods and constructors

Can C++0x PODs/aggregates have user-defined constructors and still be
PODs/aggregates? If not, why not? How about conversion operators? And what
is the difference between a POD and an aggregate anyway?

dragan

dragan wrote:
> Can C++0x PODs/aggregates have user-defined constructors and still be
> PODs/aggregates?

From [dcl.init.aggr]:
<< 1 An aggregate is an array or a class (Clause 9) with no
user-provided constructors (12.1), no private or
protected non-static data members (Clause 11), no base classes (Clause
10), and no virtual functions (10.3). >>

So, no, once you add a user-defined c-tor, it's not an aggregate.

> If not, why not?

Because that's how it's defined. Ask in 'comp.std.c++' for the
rationale behind that definition.

> How about conversion operators?

You can have conversion operators in an aggregate (according to the
definition), if other conditions are met.

> And what
> is the difference between a POD and an aggregate anyway?

And aggregate is a POD. A POD is not necessarily an aggregate.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Victor Bazarov

dragan wrote:

> Can C++0x PODs/aggregates have user-defined constructors and still be
> PODs/aggregates? If not, why not? How about conversion operators? And what
> is the difference between a POD and an aggregate anyway?

Aggregates but not PODs, both in C++03 and C++0x:

string foo[10];
struct bar {
string baz;
};

In C++0x, you can use memcpy on trivially copyable types. POD is too strict
a requirement for this - so if you just want to use memcpy on a type for
example, making a type trivially copyable would suffice, in particular:

- has no non-trivial copy constructors (12.,
— has no non-trivial copy assignment operators (13.5.3, 12., and
— has a trivial destructor (12.4).

A trivial class then is a class that is trivially copyable and that has a
trivial default constructor. F is trivial and G is trivially copyable:

struct F { Foo() = default; F(int a):a(a) { } int a; };
struct G { Foo(int a):a(a) { } int a; };

For other things, a class has to be a standard layout class. Thus is true
for "offsetof", to inspect a common initial sequence when two such structs
are in an union, etc. Look up the details in the latest draft at 9/6.

A POD is a class is trivial and a standard layout class and has no members
of non-POD etc... . Actually, i haven't found something in the c++0x
language in 2960 that still requires things to be PODs. Things either seem
to refer to standard layout classes or trivially copyable.

Johannes Schaub (litb)

Johannes Schaub (litb) wrote:
> dragan wrote:
>
>> Can C++0x PODs/aggregates have user-defined constructors and still be
>> PODs/aggregates? If not, why not? How about conversion operators? And what
>> is the difference between a POD and an aggregate anyway?
>
> Aggregates but not PODs, both in C++03 and C++0x:
>
> string foo[10];
> struct bar {
> string baz;
> };
>

std::string (if you are referring to that here) is not POD, therefore
that structure can not be an aggregate.

> In C++0x, you can use memcpy on trivially copyable types. POD is too strict
> a requirement for this - so if you just want to use memcpy on a type for
> example, making a type trivially copyable would suffice, in particular:
>
> - has no non-trivial copy constructors (12.,
> — has no non-trivial copy assignment operators (13.5.3, 12., and
> — has a trivial destructor (12.4).
>
> A trivial class then is a class that is trivially copyable and that has a
> trivial default constructor. F is trivial and G is trivially copyable:
>
> struct F { Foo() = default; F(int a):a(a) { } int a; };

What is that default thing???

> struct G { Foo(int a):a(a) { } int a; };
>
> For other things, a class has to be a standard layout class. Thus is true
> for "offsetof", to inspect a common initial sequence when two such structs
> are in an union, etc. Look up the details in the latest draft at 9/6.
>
> A POD is a class is trivial and a standard layout class and has no members
> of non-POD etc... . Actually, i haven't found something in the c++0x
> language in 2960 that still requires things to be PODs. Things either seem
> to refer to standard layout classes or trivially copyable.


I think you got that wrong. As far as I know (might be wrong), but
agregate is defined as an array or class that has none of the following
characretistics:
1) user declared constructors
2) private or protected non-static data members
3) base classes
4) virtual functions

--
Bolje je ziveti sto godina kao bogatun, nego jedan dan kao siromah!

Vladimir Jovic

Vladimir Jovic wrote:

> Johannes Schaub (litb) wrote:
>> dragan wrote:
>>
>>> Can C++0x PODs/aggregates have user-defined constructors and still be
>>> PODs/aggregates? If not, why not? How about conversion operators? And
>>> what is the difference between a POD and an aggregate anyway?
>>
>> Aggregates but not PODs, both in C++03 and C++0x:
>>
>> string foo[10];
>> struct bar {
>> string baz;
>> };
>>
>
> std::string (if you are referring to that here) is not POD, therefore
> that structure can not be an aggregate.
>
That has nothing to do with it not being an aggregate. Non-PODs can be
aggregates, of course. Please gimme some standard legalese to prove me wrong


>> In C++0x, you can use memcpy on trivially copyable types. POD is too
>> strict a requirement for this - so if you just want to use memcpy on a
>> type for example, making a type trivially copyable would suffice, in
>> particular:
>>
>> - has no non-trivial copy constructors (12.,
>> — has no non-trivial copy assignment operators (13.5.3, 12., and
>> — has a trivial destructor (12.4).
>>
>> A trivial class then is a class that is trivially copyable and that has a
>> trivial default constructor. F is trivial and G is trivially copyable:
>>
>> struct F { Foo() = default; F(int a):a(a) { } int a; };
>
> What is that default thing???
>
This is a C++0x feature, and it means that the user declared constructor
will have a default implementation (which is trivial here).

>> struct G { Foo(int a):a(a) { } int a; };
>>
>> For other things, a class has to be a standard layout class. Thus is true
>> for "offsetof", to inspect a common initial sequence when two such
>> structs are in an union, etc. Look up the details in the latest draft at
>> 9/6.
>>
>> A POD is a class is trivial and a standard layout class and has no
>> members of non-POD etc... . Actually, i haven't found something in the
>> c++0x language in 2960 that still requires things to be PODs. Things
>> either seem to refer to standard layout classes or trivially copyable.
>
>
> I think you got that wrong. As far as I know (might be wrong), but
> agregate is defined as an array or class that has none of the following
> characretistics:
> 1) user declared constructors
> 2) private or protected non-static data members
> 3) base classes
> 4) virtual functions
>
Yes, that's right (for c++03. For C++0x, "user declared" is changed to "user
provided", as you can declare a constructor yourself, but then default it).
So an aggregate can surely contain std::string However, where do i say
something contradictory?

Johannes Schaub (litb)

On Oct 28, 7:02 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> dragan wrote:
> > Can C++0x PODs/aggregates have user-defined constructors and
> > still be PODs/aggregates?

> From [dcl.init.aggr]:
> << 1 An aggregate is an array or a class (Clause 9) with no
> user-provided constructors (12.1), no private or
> protected non-static data members (Clause 11), no base classes (Clause
> 10), and no virtual functions (10.3). >>

> So, no, once you add a user-defined c-tor, it's not an aggregate.

> > If not, why not?

> Because that's how it's defined. Ask in 'comp.std.c++' for
> the rationale behind that definition.

The rationale is probably simply that they needed the
distinction for some reason. In C++03, the distinction is
clear: aggregates can only be initialized using the aggregate
initialization syntax; other things can't be initialized using
the aggregate initialized syntax. In C++0x, there will be a
universal initialization syntax, which works for both aggregates
and non aggregates, but the semantics are still different: when
initializing an aggregate, you specify the initializer for each
member; when initializing a non-aggregate, you specify the
arguments for a constructor.

> > How about conversion operators?

> You can have conversion operators in an aggregate (according
> to the definition), if other conditions are met.

> > And what is the difference between a POD and an aggregate
> > anyway?

> And aggregate is a POD. A POD is not necessarily an
> aggregate.

Intuitively: an aggregate is determined superficially: an array
or a class with no user defined constructor, but elements of the
array or class aren't necessarily aggregates. A POD is defined
"deeply": for something to be a POD, all of its elements must be
POD's, recursively. There's more to it than that, of course.
The important difference is that whether something is an
aggregate or not determines how it is initialized (in C++03) or
what the initialization arguments mean (in C++0x). The
difference between a POD and a non-POD is that a POD has
constructors and destructors which are effectively no-ops, and
an assignment operator which is the equivalent of memcpy; this
plays a role in various contexts.

--
James Kanze

James Kanze

On Oct 29, 7:31 am, Vladimir Jovic <vladasp...@gmail.com> wrote:
> Johannes Schaub (litb) wrote:
> > dragan wrote:

> >> Can C++0x PODs/aggregates have user-defined constructors
> >> and still be PODs/aggregates? If not, why not? How about
> >> conversion operators? And what is the difference between a
> >> POD and an aggregate anyway?

> > Aggregates but not PODs, both in C++03 and C++0x:

> > string foo[10];
> > struct bar {
> > string baz;
> > };

> std::string (if you are referring to that here) is not POD,
> therefore that structure can not be an aggregate.

std::string is not an aggregate, but bar is. Aggregation is
determined very superficially; if the class has no user defined
constructor or private data members, it is an aggregate.

> > In C++0x, you can use memcpy on trivially copyable types.
> > POD is too strict a requirement for this - so if you just
> > want to use memcpy on a type for example, making a type
> > trivially copyable would suffice, in particular:

> > - has no non-trivial copy constructors (12.,
> > — has no non-trivial copy assignment operators (13.5.3, 12., and
> > — has a trivial destructor (12.4).

> > A trivial class then is a class that is trivially copyable
> > and that has a trivial default constructor. F is trivial and
> > G is trivially copyable:

> > struct F { Foo() = default; F(int a):a(a) { } int a; };

> What is that default thing???

Something new to C++0x. It just means that the compiler should
use the default implementation. In this case, I suppose that
Foo is a typo for F, and it is used to say that the default
constructor is the compiler generated default (and not absent,
as it would be otherwise in the presence of other constructors).

--
James Kanze

James Kanze

James Kanze wrote:

> On Oct 29, 7:31 am, Vladimir Jovic <vladasp...@gmail.com> wrote:
>> Johannes Schaub (litb) wrote:
>> > In C++0x, you can use memcpy on trivially copyable types.
>> > POD is too strict a requirement for this - so if you just
>> > want to use memcpy on a type for example, making a type
>> > trivially copyable would suffice, in particular:
>
>> > - has no non-trivial copy constructors (12.,
>> > — has no non-trivial copy assignment operators (13.5.3, 12., and
>> > — has a trivial destructor (12.4).
>
>> > A trivial class then is a class that is trivially copyable
>> > and that has a trivial default constructor. F is trivial and
>> > G is trivially copyable:
>
>> > struct F { Foo() = default; F(int a):a(a) { } int a; };
>
>> What is that default thing???
>
> Something new to C++0x. It just means that the compiler should
> use the default implementation. In this case, I suppose that
> Foo is a typo for F, and it is used to say that the default
> constructor is the compiler generated default (and not absent,
> as it would be otherwise in the presence of other constructors).
>
Oops, yes i typo'ed. Im sorry for any confusion caused

Johannes Schaub (litb)

Johannes Schaub (litb) wrote:
> Vladimir Jovic wrote:
>>> string foo[10];
>>> struct bar {
>>> string baz;
>>> };
>>>
>> std::string (if you are referring to that here) is not POD, therefore
>> that structure can not be an aggregate.
>>
> That has nothing to do with it not being an aggregate. Non-PODs can be
> aggregates, of course. Please gimme some standard legalese to prove me wrong
>
>

<cut some stuff>

>> I think you got that wrong. As far as I know (might be wrong), but
>> agregate is defined as an array or class that has none of the following
>> characretistics:
>> 1) user declared constructors
>> 2) private or protected non-static data members
>> 3) base classes
>> 4) virtual functions
>>
> Yes, that's right (for c++03. For C++0x, "user declared" is changed to "user
> provided", as you can declare a constructor yourself, but then default it).
> So an aggregate can surely contain std::string However, where do i say
> something contradictory?

doh my mistake. An Aggregate can contain non-POD, but POD can't contain
non-POD
sorry


--
Bolje je ziveti sto godina kao bogatun, nego jedan dan kao siromah!

Vladimir Jovic

James Kanze wrote:
> On Oct 28, 7:02 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> dragan wrote:
>>> And what is the difference between a POD and an aggregate
>>> anyway?
>
>> And aggregate is a POD. A POD is not necessarily an
>> aggregate.
>
> Intuitively: an aggregate is determined superficially: an array
> or a class with no user defined constructor, but elements of the
> array or class aren't necessarily aggregates. A POD is defined
> "deeply": for something to be a POD, all of its elements must be
> POD's, recursively. There's more to it than that, of course.
> The important difference is that whether something is an
> aggregate or not determines how it is initialized (in C++03) or
> what the initialization arguments mean (in C++0x). The
> difference between a POD and a non-POD is that a POD has
> constructors and destructors which are effectively no-ops, and
> an assignment operator which is the equivalent of memcpy; this
> plays a role in various contexts.

OK, so I am wrong saying that an aggregate is POD. An aggregate is POD
*iff* all of its members/elements are POD.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Victor Bazarov