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_check.h: In instantiation of
'__gnu_cxx::_SGIAssignableConcept<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_check.h:216: error:
'__gnu_cxx::_SGIAssignableConcept<_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<class 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

[Jim Langston]

ph**************@gmail.com 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_check.h: In instantiation of
'__gnu_cxx::_SGIAssignableConcept<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_check.h:216: error:
'__gnu_cxx::_SGIAssignableConcept<_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<class 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.

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.

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.

--
Jim Langston
ta*******@rocketmail.com

[phil.pellouchoud]

Here's exactly what i get when I try to compile that code:

C:\>type foo.cpp
#include <list>

class CFoo
{
private:
std::list<CFoom_children;

};

int main()
{
CFoo Foo;

}
C:\>gcc -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.3.0/configure --prefix=/mingw --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++,ada,
java --disable-win32-registry --disable-sjlj-exceptions --enable-
libstdcxx-debug --enable-version-specific-runtime-libs
--with-gmp=/mingw/src/gcc/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-
mpfr-root --enable-libgcj --enable-concept-checks
--enable-shared
Thread model: win32
gcc version 4.3.0 (GCC)

C:\>gcc -o foo foo.cpp
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h: In instantiation of '__gnu_cxx::_S
GIAssignableConcept<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'
foo.cpp:6: instantiated from here
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h:216: error: '__gnu_cxx::_SGIAssigna
bleConcept<_Tp>::__a' has incomplete type
foo.cpp:4: error: forward declaration of 'class CFoo'
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h: In member function 'void __gnu_cxx
::_SGIAssignableConcept<_Tp>::__constraints() [with _Tp = 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'
foo.cpp:6: instantiated from here
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h:208: error: using invalid field '__
gnu_cxx::_SGIAssignableConcept<_Tp>::__a'
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h:209: error: using invalid field '__
gnu_cxx::_SGIAssignableConcept<_Tp>::__a'
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h:209: error: using invalid field '__
gnu_cxx::_SGIAssignableConcept<_Tp>::__a'
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'
foo.cpp:6: instantiated from here
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h:210: error: using invalid field '__
gnu_cxx::_SGIAssignableConcept<_Tp>::__a'
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h: In member function 'void __gnu_cxx
::_SGIAssignableConcept<_Tp>::__const_constraints( const _Tp&) [with
_Tp = CFoo]':
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h:210: instantiated from 'void __gn
u_cxx::_SGIAssignableConcept<_Tp>::__constraints() [with _Tp = 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'
foo.cpp:6: instantiated from here
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h:214: error: using invalid field '__
gnu_cxx::_SGIAssignableConcept<_Tp>::__a'

C:\>

[Ian Collins]

ph**************@gmail.com wrote:

Here's exactly what i get when I try to compile that code:

C:\>type foo.cpp
#include <list>

class CFoo
{
private:
std::list<CFoom_children;

};

int main()
{
CFoo Foo;

}

C:\>gcc -o foo foo.cpp
c:\mingw\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/
boost_concept_check.h: In instantiation of '__gnu_cxx::_S
GIAssignableConcept<CFoo>':

<snip>

Looks like your compiler isn't configured correctly, try a gcc group.

--
Ian Collins.

[kwikius]

On Apr 28, 7:33*pm, "Jim Langston" <[e-mail]:

[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_check.h: In instantiation of
'__gnu_cxx::_SGIAssignableConcept<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_check.h:216: error:
'__gnu_cxx::_SGIAssignableConcept<_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<class 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.

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.

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.

IMO gcc is correct. You could have a list of pointers or refs to CFoo
but not recursive types. One workaround *may* be to use a typedef
alias for CFoo. That may fool gcc, but I think its technically correct
to call this an error.

regards
Andy Little

[Ian Collins]

kwikius wrote:

On Apr 28, 7:33 pm, "Jim Langston" <[e-mail]:

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

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.

IMO gcc is correct. You could have a list of pointers or refs to CFoo
but not recursive types. One workaround *may* be to use a typedef
alias for CFoo. That may fool gcc, but I think its technically correct
to call this an error.

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.

In effect, it's just like writing

#include <list>

class X;

class CFoo
{
private:
std::list<Xm_children;
};

class X {};

int main()
{
CFoo Foo;
}

The complete class definition is not required until std::list's default
constructor is instantiated in main().

--
Ian Collins.

[kwikius]

"Ian Collins" <ia******@hotmail.comwrote in message
news:67*************@mid.individual.net...

kwikius wrote:

>On Apr 28, 7:33 pm, "Jim Langston" <[e-mail]:

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

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.

IMO gcc is correct. You could have a list of pointers or refs to CFoo
but not recursive types. One workaround *may* be to use a typedef
alias for CFoo. That may fool gcc, but I think its technically correct
to call this an error.

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.

Various things to try to diagnose the problem. Try some other dummy template
class than std::list.
If that succeeds then std::list is concept checking and wont allow itself to
be instantiated without a complete type or some such

There is presumably an option to turn it off . ..

regards
Andy Little

[Ian Collins]

kwikius wrote:

"Ian Collins" <ia******@hotmail.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.

--
Ian Collins.

[kwikius]

"Ian Collins" <ia******@hotmail.comwrote in message
news:67*************@mid.individual.net...

kwikius wrote:

>"Ian Collins" <ia******@hotmail.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.

regards
Andy Little

[Ian Collins]

kwikius wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:67*************@mid.individual.net...

>kwikius wrote:

>>"Ian Collins" <ia******@hotmail.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******@hotmail.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*******@rocketmail.com

[kwikius]

"Jim Langston" <ta*******@rocketmail.comwrote in message
news:9S****************@newsfe05.lga...

Ian Collins wrote:

>kwikius wrote:

>>"Ian Collins" <ia******@hotmail.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?

FWIW following gives something similar. The trick is to make some
dependency, which must be going on in the O.P.

#include <list>

template<typename T>
struct dummy : T{ };

struct CFoo {
dummy<CFoomy_list;
};

int main()
{
CFoo foo;
}

[James Kanze]

On Apr 28, 8:33 pm, "Jim Langston" <[e-mail]:

[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_check.h: In instantiation of
'__gnu_cxx::_SGIAssignableConcept<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_check.h:216: error:
'__gnu_cxx::_SGIAssignableConcept<_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<class 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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Apr 29, 12:47 am, "kwikius" <[e-mail]:

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

news:67*************@mid.individual.net...

kwikius wrote:

"Ian Collins" <[e-mail]:

>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_CONCEPT_CHECKS, i.e. specify the option
-D_GLIBCXX_CONCEPT_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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ian Collins]

James Kanze wrote:

On Apr 28, 8:33 pm, "Jim Langston" <[e-mail]:

>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******@hotmail.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]:

James Kanze wrote:

On Apr 28, 8:33 pm, "Jim Langston" <[e-mail]:

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Cynic]

On Apr 29, 5:00 pm, James Kanze <[e-mail]:

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

James Kanze wrote:

On Apr 28, 8:33 pm, "Jim Langston" <[e-mail]:
>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:[e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
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 <[e-mail]:

On Apr 29, 12:47 am, "kwikius" <[e-mail]:

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

kwikius wrote:
>"Ian Collins" <[e-mail]:
>>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_CONCEPT_CHECKS, i.e. specify the option
-D_GLIBCXX_CONCEPT_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:[e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
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_CONCEPT_CHECKS

at the top of the sample app:

---- cut here ----
#undef _GLIBCXX_CONCEPT_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]:

[...]

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Apr 29, 6:09 pm, [e-mail] wrote:

On Apr 29, 1:46 am, James Kanze <[e-mail]:

[...]

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_CONCEPT_CHECKS, i.e. specify the option
-D_GLIBCXX_CONCEPT_CHECKS.

[...]

did the default behavior change in gcc 4.3?

I don't know. The latest version I currently have installed
here is 4.1.0. (I really should install 4.3, but I haven't had
time as yet.)

I know that the g++ people are implementing a preliminary
version of concepts, which will change the way this is handled.

i seem to get it by default; and I don't know how to turn it
off. I did try doing a
#undefine _GLIBCXX_CONCEPT_CHECKS

at the top of the sample app:

---- cut here ----
#undef _GLIBCXX_CONCEPT_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...

Just compile with an older version of g++. But why? It will be
a required error in the future, so you won't be able to upgrade
compilers, or us any other more recent compiler, if you do so.
The code is illegal today; it just happens to work with some
compilers, by chance, but even then, the compiler vendor doesn't
guarantee it.

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

[Ian Collins]

James Kanze wrote:

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

[...]

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

That's the bit I don't get - the compiler can't compile the class if the
size of a member is unknown, so why should this be undefined behaviour?
Implementation defined maybe, but undefined?

--
Ian Collins.

[James Kanze]

On Apr 29, 4:45 pm, Cynic <[e-mail]:

On Apr 29, 5:00 pm, James Kanze <[e-mail]:

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

James Kanze wrote:
On Apr 28, 8:33 pm, "Jim Langston" <[e-mail]:
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.)

this would create a pointer to a LIST?

Yes. And since declaring a pointer to the type doesn't require
the type (i.e. the instantiation of std::list) to be complete,
it doesn't trigger instantiation of the template.

and would it help then if the std::list is created outside the
class?

Yes. As long as the type in question is complete whenever the
class is instantiated. The formal rules as to when something is
intantiated are fairly complex, but a rough approximation,
sufficient for most concerns, is simply that the class itself
will be instantiated anytime the compiler needs a complete type,
or something in the class, and the class members will be
instantiated anytime they are used.

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