using a class inside a class.

[phil.pellouchoud]

I did some searching online and i couldn't find anything in reference
to this.

I am using MinGW, gcc 4.3 and am having the following compilation
issue:

class CFoo
{
public:
...
private:
std::list<CFoom _children;
};

The complaint from the compiler looks like this:

c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_c heck.h: In instantiation of
'__gnu_cxx::_SG IAssignableConc ept<CFoo>':
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
stl_list.h:420: instantiated from 'std::list<CFoo ,
std::allocator< CFoo'
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_c heck.h:216: error:
'__gnu_cxx::_SG IAssignableConc ept<_Tp>::__a' has incomplete type

So, basically, I think what it's saying is that it doesn't know how to
build the class because CFoo hasn't been defined by the time it's
trying to create it (i.e. incomplete type). I tried adding
"std::list<clas s CFoo>" as well, but that didn't work either. This
compiles on visual studio with some warnings.

I can make this work by making it "std::list<CFoo *>", but I'm
wondering if there's a way to get this to work as defined.

thanks for listening.

-phil

[Ian Collins]

kwikius wrote:

"Ian Collins" <ia******@hotma il.comwrote in message
news:67******** *****@mid.indiv idual.net...

>kwikius wrote:

>>"Ian Collins" <ia******@hotma il.comwrote:
Why? The class declares m_children to be a list of CFoo. It does not
attempt to use any members of std::list that require a complete type.
Ah as to Why ... I Dunno. Hopefully someone of a more technical nature
will
help out as to why. From the error messages gcc is using C++0x style
Concept
checking.

It does, doesn't it? I thought that was a little odd, I didn't think
gcc had built in boost libraries.

Ahha yes its not C++0x Concepts, its old style concept checking . Theres
bound to be an option to turn that off.
Probbably a macro somewhere

Its all legit AFAIK.
After all std::list may want to for example instantiate some private
template type of allocate<sizeof (T)>
when its constructed for which it would obviously need the complete type.

True, but that only happens when a CFoo is created and fully declared.

--
Ian Collins.

[Jim Langston]

Ian Collins wrote:

kwikius wrote:

>"Ian Collins" <ia******@hotma il.comwrote:

>>>>
Why? The class declares m_children to be a list of CFoo. It does
not attempt to use any members of std::list that require a complete
type.

Ah as to Why ... I Dunno. Hopefully someone of a more technical
nature will help out as to why. From the error messages gcc is using
C++0x style Concept checking.

It does, doesn't it? I thought that was a little odd, I didn't think
gcc had built in boost libraries.

That had thrown me off also, the boost error messages on something that has
nothing to do with boost. I wonder if it's some compiler switch?

--
Jim Langston
ta*******@rocke tmail.com

[James Kanze]

On Apr 28, 8:33 pm, "Jim Langston" <tazmas...@rock etmail.comwrote :

phil.pellouch.. [e-mail] wrote:

I did some searching online and i couldn't find anything in reference
to this.

I am using MinGW, gcc 4.3 and am having the following compilation
issue:

class CFoo
{
public:
...
private:
std::list<CFoom _children;
};

The complaint from the compiler looks like this:

c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_c heck.h: In instantiation of
'__gnu_cxx::_SG IAssignableConc ept<CFoo>':
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
stl_list.h:420: instantiated from 'std::list<CFoo ,
std::allocator< CFoo'
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_c heck.h:216: error:
'__gnu_cxx::_SG IAssignableConc ept<_Tp>::__a' has incomplete type

So, basically, I think what it's saying is that it doesn't know how to
build the class because CFoo hasn't been defined by the time it's
trying to create it (i.e. incomplete type). I tried adding
"std::list<clas s CFoo>" as well, but that didn't work either. This
compiles on visual studio with some warnings.

I can make this work by making it "std::list<CFoo *>", but I'm
wondering if there's a way to get this to work as defined.

Nothing standards conformant.

All I can tell you is I've done this exact same thing in the past
successfully in both Microsoft Visual C++ .net 2003 and DevC++. Here is
something that compiles sucessfully in Microsoft Visual C++ .net 2003:

#include <list>

class CFoo
{
private:
std::list<CFoom _children;
};

int main()
{
CFoo Foo;
}

No warnings, no errors.

That's what's so nice about undefined behavior. The fact that
it works doesn't prove anything.

I don't know why your version of gcc is complaining, I don't
think it should, AFAIK this is perfectly legal, although I
haven't read the standard on it.

§17.4.3.6/2:

In particular, the effects are undefined in the
following cases:

[...]

-- if an incomplete type (3.9) is used as a template
argument when instantiating a template component.

A class is only a complete type after the closing braces, so
your code has undefined behavior. (The standard could have
allowed incomplete types for certain specific cases, but it
didn't.)

The current working draft still has basically the same words
(with an "unless specifically allowed" exception, for e.g.
shared_ptr). I believe, however, that it is the intent to
require an error here once concepts have been added to the
language.

G++ uses boost::concepts (or something derived from it, I'm
not sure) to generate errors in most of cases, rather than
letting the undefined behavior through.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Apr 29, 12:47 am, "kwikius" <a...@servocomm .freeserve.co.u kwrote:

"Ian Collins" <[e-mail] mwrote in message

news:67******** *****@mid.indiv idual.net...

kwikius wrote:

"Ian Collins" <[e-mail] mwrote:

>Why? The class declares m_children to be a list of CFoo.
It does not attempt to use any members of std::list that
require a complete type.

Ah as to Why ... I Dunno. Hopefully someone of a more
technical nature will help out as to why. From the error
messages gcc is using C++0x style Concept checking.

It does, doesn't it? I thought that was a little odd, I
didn't think gcc had built in boost libraries.

Ahha yes its not C++0x Concepts, its old style concept
checking. Theres bound to be an option to turn that off.
Probbably a macro somewhere

It's off by default (but I always turn it on). To get it, you
need to define _GLIBCXX_CONCEP T_CHECKS, i.e. specify the option
-D_GLIBCXX_CONCE PT_CHECKS.

Its all legit AFAIK.
After all std::list may want to for example instantiate some private
template type of allocate<sizeof (T)>
when its constructed for which it would obviously need the complete type.

I don't think that there's any particular justification for this
particular class. The rule in C++-03 was general: only complete
types when instantiating a template, regardless. The committee
made no effort to second guess what implementors might or might
not want to do in specific cases.

As far as I know, there's also no movement to change this
particular rule (although some of the new classes, like
shared_ptr, are an explicit exception, and other rules have been
loosened---std::list will no longer require assignable, for
example).

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ian Collins]

James Kanze wrote:

On Apr 28, 8:33 pm, "Jim Langston" <tazmas...@rock etmail.comwrote :

>All I can tell you is I've done this exact same thing in the past
successfully in both Microsoft Visual C++ .net 2003 and DevC++. Here is
something that compiles sucessfully in Microsoft Visual C++ .net 2003:

>#include <list>

>class CFoo
{
private:
std::list<CFoom _children;
};

>int main()
{
CFoo Foo;
}

>No warnings, no errors.

That's what's so nice about undefined behavior. The fact that
it works doesn't prove anything.

>I don't know why your version of gcc is complaining, I don't
think it should, AFAIK this is perfectly legal, although I
haven't read the standard on it.

§17.4.3.6/2:

In particular, the effects are undefined in the
following cases:

[...]

-- if an incomplete type (3.9) is used as a template
argument when instantiating a template component.

A class is only a complete type after the closing braces, so
your code has undefined behavior. (The standard could have
allowed incomplete types for certain specific cases, but it
didn't.)

But isn't the template component being instantiated in main after the
class is complete?

--
Ian Collins.

[Kai-Uwe Bux]

Jim Langston wrote:

Ian Collins wrote:

>kwikius wrote:

>>"Ian Collins" <ia******@hotma il.comwrote:
>
Why? The class declares m_children to be a list of CFoo. It does
not attempt to use any members of std::list that require a complete
type.

Ah as to Why ... I Dunno. Hopefully someone of a more technical
nature will help out as to why.

With regard to std::list, no particular reason. The standard just requires
all types to be complete when used with the STL components. The committee
just did not include an exception for std::list, even though any straight
forward implementation of std::list that does not do something overly smart
or funny will work gracefully with incomplete types. (I consider it a
defect in the standard, but I think that is just me: the drafts for C++0X
have the same language.)

>>From the error messages gcc is using
C++0x style Concept checking.

It does, doesn't it? I thought that was a little odd, I didn't think
gcc had built in boost libraries.

That had thrown me off also, the boost error messages on something that
has
nothing to do with boost. I wonder if it's some compiler switch?

[OT] Nope. It depends on how g++ and in particular the STL that ships with
it are built on your machine. If you make it with --enable-concept-checks,
you get those errors. If you disable concept-checks, std::list will behave
nicely with regard to incomplete types (although that is not guaranteed by
the standard nor by the g++ folks).
Best

Kai-Uwe Bux

[James Kanze]

On Apr 29, 10:57 am, Ian Collins <[e-mail] mwrote:

James Kanze wrote:

On Apr 28, 8:33 pm, "Jim Langston" <tazmas...@rock etmail.comwrote :

All I can tell you is I've done this exact same thing in the past
successfully in both Microsoft Visual C++ .net 2003 and DevC++. Here is
something that compiles sucessfully in Microsoft Visual C++ .net 2003:

#include <list>

class CFoo
{
private:
std::list<CFoom _children;
};

int main()
{
CFoo Foo;
}

No warnings, no errors.

That's what's so nice about undefined behavior. The fact that
it works doesn't prove anything.

I don't know why your version of gcc is complaining, I don't
think it should, AFAIK this is perfectly legal, although I
haven't read the standard on it.

§17.4.3.6/2:

In particular, the effects are undefined in the
following cases:

[...]

-- if an incomplete type (3.9) is used as a template
argument when instantiating a template component.

A class is only a complete type after the closing braces, so
your code has undefined behavior. (The standard could have
allowed incomplete types for certain specific cases, but it
didn't.)

But isn't the template component being instantiated in main
after the class is complete?

The class itself will be instantiated anytime it is used in a
context where a complete type is required. (How could it be
otherwise?) Class members (functions, static data members) will
be instantiated when (and only when) they are used. Since only
complete types can be used as member variables, the class itself
must be instantiated in CFoo. (Note that declaring the type as
"std::list< CFoo >* m_children" should work.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Cynic]

On Apr 29, 5:00 pm, James Kanze <james.ka...@gm ail.comwrote:

On Apr 29, 10:57 am, Ian Collins <[e-mail] mwrote:

James Kanze wrote:

On Apr 28, 8:33 pm, "Jim Langston" <tazmas...@rock etmail.comwrote :
>All I can tell you is I've done this exact same thing in the past
>successfully in both Microsoft Visual C++ .net 2003 and DevC++. Hereis
>something that compiles sucessfully in Microsoft Visual C++ .net 2003:
>#include <list>
>class CFoo
>{
>private:
> std::list<CFoom _children;
>};
>int main()
>{
> CFoo Foo;
>}
>No warnings, no errors.
That's what's so nice about undefined behavior. The fact that
it works doesn't prove anything.
>I don't know why your version of gcc is complaining, I don't
>think it should, AFAIK this is perfectly legal, although I
>haven't read the standard on it.
§17.4.3.6/2:
In particular, the effects are undefined in the
following cases:
[...]
-- if an incomplete type (3.9) is used as a template
argument when instantiating a template component.
A class is only a complete type after the closing braces, so
your code has undefined behavior. (The standard could have
allowed incomplete types for certain specific cases, but it
didn't.)

But isn't the template component being instantiated in main
after the class is complete?

The class itself will be instantiated anytime it is used in a
context where a complete type is required. (How could it be
otherwise?) Class members (functions, static data members) will
be instantiated when (and only when) they are used. Since only
complete types can be used as member variables, the class itself
must be instantiated in CFoo. (Note that declaring the type as
"std::list< CFoo >* m_children" should work.)

--
James Kanze (GABI Software) email:james.ka. [e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

>(Note that declaring the type as
"std::list< CFoo >* m_children" should work.)

this would create a pointer to a LIST?
and would it help then if the std::list is created outside the
class?

[phil.pellouchoud]

On Apr 29, 1:46 am, James Kanze <james.ka...@gm ail.comwrote:

On Apr 29, 12:47 am, "kwikius" <a...@servocomm .freeserve.co.u kwrote:

"Ian Collins" <[e-mail] mwrote in message
news:67******** *****@mid.indiv idual.net...

kwikius wrote:
>"Ian Collins" <[e-mail] mwrote:
>>Why? The class declares m_children to be a list of CFoo.
>>It does not attempt to use any members of std::list that
>>require a complete type.
>Ah as to Why ... I Dunno. Hopefully someone of a more
>technical nature will help out as to why. From the error
>messages gcc is using C++0x style Concept checking.
It does, doesn't it? I thought that was a little odd, I
didn't think gcc had built in boost libraries.

Ahha yes its not C++0x Concepts, its old style concept
checking. Theres bound to be an option to turn that off.
Probbably a macro somewhere

It's off by default (but I always turn it on). To get it, you
need to define _GLIBCXX_CONCEP T_CHECKS, i.e. specify the option
-D_GLIBCXX_CONCE PT_CHECKS.

Its all legit AFAIK.
After all std::list may want to for example instantiate some private
template type of allocate<sizeof (T)>
when its constructed for which it would obviously need the complete type..

I don't think that there's any particular justification for this
particular class. The rule in C++-03 was general: only complete
types when instantiating a template, regardless. The committee
made no effort to second guess what implementors might or might
not want to do in specific cases.

As far as I know, there's also no movement to change this
particular rule (although some of the new classes, like
shared_ptr, are an explicit exception, and other rules have been
loosened---std::list will no longer require assignable, for
example).

--
James Kanze (GABI Software) email:james.ka. [e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

did the default behavior change in gcc 4.3? i seem to get it by
default; and I don't know how to turn it off. I did try doing a
#undefine _GLIBCXX_CONCEP T_CHECKS

at the top of the sample app:

---- cut here ----
#undef _GLIBCXX_CONCEP T_CHECKS

#include <list>

class CFoo
{
private:
std::list<CFoom _children;

};

int main()
{
CFoo Foo;
}
---- cut here ----

But i still get the same error. I would love to be able to simply
disable it if I could...

-phil

[James Kanze]

On Apr 29, 10:13 pm, Ian Collins <[e-mail] mwrote:

[...]

It's not uncommon for classes to have std::auto_ptr members
which use incomplete types.

It's undefined behavior, so there will be no such cases in
correct code. (Strangely enough, however, g++ doesn't seem to
cover this case in its concept checking. And of course,
typically, there won't be any reason for it not to work, at
least on machines where all object pointers have the same size
and representation. )

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]