class containing a list of itself

[Old Wolf]

The following code causes a segfault for me, why?

#include <list>

template<typename T>
struct Tree
{
std::list< Tree<T> > child;
};

int main()
{
Tree<int> bar;
std::list< Tree<int> > foo;
foo.push_back(bar);
}

If I reverse the order of the 'foo' and 'bar' declarations then I instead
get a compiler error "Compiler could not generate default constructor
for class Tree<int>". The problem is the same with other types instead of
'int', but if I change list to vector or deque then there is no problem
at all.

 

[Sharad Kala]

The following code causes a segfault for me, why?
[snip]
If I reverse the order of the 'foo' and 'bar' declarations then I instead
get a compiler error "Compiler could not generate default constructor
for class Tree<int>". The problem is the same with other types instead of
'int', but if I change list to vector or deque then there is no problem
at all.

Which compiler are you using ? I can't see both the problems on VC 7.1 and
g++ 3.3.1.

-Sharad

 

[Rob Williscroft]

Old Wolf wrote in in
comp.lang.c++:

The following code causes a segfault for me, why?

#include <list>

template<typename T>
struct Tree
{
std::list< Tree<T> > child;

};

int main()
{
Tree<int> bar;
std::list< Tree<int> > foo;
foo.push_back(bar);
}

If I reverse the order of the 'foo' and 'bar' declarations then I
instead
get a compiler error "Compiler could not generate default constructor
for class Tree<int>". The problem is the same with other types instead
of 'int', but if I change list to vector or deque then there is no
problem at all.

It just so happens that vector and deque on you implementation *don't*
require a complete type, IOW it may work but it isn't portable.

The good news is this is really a Quality of Implementation issue.
I.e. there is no "good" reason the the standard library containers
*need* to require a complete argument type.

So if you're not worried about having complete portablity you could
upgrade your standard library, both g++ and dinkumware compile
your code without any problem. I don't now about stlport but my
experience with rougewave suggest it will not. But your code will
be non-standard until/unless the standard gets changed.

Rob.

 

[Sharad Kala]

But your code will

be non-standard until/unless the standard gets changed.

I think Standard does mention about this in Section 14.3.1/2
" ...[Note: a template type argument may be an incomplete type. ] "

-Sharad

 

[Rob Williscroft]

Sharad Kala wrote in in comp.lang.c++:

With hindsight I should have possibly been clearer that the requirment
for completeness of argument types, is only for instantiation *not*
for declaration:

#include <list>

struct X;

extern std::list< X > xlist;

struct X {};

I think Standard does mention about this in Section 14.3.1/2
" ...[Note: a template type argument may be an incomplete type. ] "

14.3.1 == Templates / Template type arguments.

Not really relevent to wether or not std::list< T > can take
an incomplete T and be instantiated *before* T is complete.

IOW: you can always (*) declare a specialization which has an incomplete
argument type, what is dependant on the template defenition is wether
you can instantiate such a specialization.

*) Unless such a declaration requires instantition of an
un-instantiatable specialization:

template < typename > struct empty {};

template < typename T, typename U = typename empty< T >::type >
struct no
{
};

extern no< int > nope;

Rob.

 

[tom_usenet]

But your code will
be non-standard until/unless the standard gets changed.

I think Standard does mention about this in Section 14.3.1/2
" ...[Note: a template type argument may be an incomplete type. ] "

17.4.3.6 Other functions
1 In certain cases (replacement functions, handler functions,
operations on types used to instantiate standard library template
components), the C + + Standard Library depends on components supplied
by a C + + program. If these components do not meet their
requirements, the Standard places no requirements on the
implementation.
2 In particular, the effects are undefined in the following cases:
[snip]
— if an incomplete type (3.9) is used as a template argument when
instantiating a template component.

Tom

 

[Old Wolf]

2 In particular, the effects are undefined in the following cases:
[snip]
? if an incomplete type (3.9) is used as a template argument when
instantiating a template component.

I think I am confused about the meaning of "instantiating"?

#include <list>

template<typename T>
struct Tree
{
std::list< Tree<T> > child;

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
declaration (no objects are yet created)

};

int main()
{
Tree<int> bar;

^^^^^^^^^^^^^^
instantiation (a 'Tree<int>' object is created, which involves
creation of any sub-objects of Tree<int>).
Surely at this point, Tree<int> is a complete type,

 

[Rob Williscroft]

Old Wolf wrote in in
comp.lang.c++:

2 In particular, the effects are undefined in the following cases:
[snip]
? if an incomplete type (3.9) is used as a template argument when
instantiating a template component.

I think I am confused about the meaning of "instantiating"?

Its when a template (class or function) is used to create a new
type or function (a specialization in standardeze).

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
declaration (no objects are yet created)

Correct, and the declaration isn't the problem.

^^^^^^^^^^^^^^
instantiation (a 'Tree<int>' object is created, which involves
creation of any sub-objects of Tree<int>).

Surely at this point, Tree<int> is a complete type,
so std::list< Tree<int> > would be OK.

Yes, but instantiating Tree< int > requires that Tree< int >

Note: with class templates "complete" and "instantiated" are
equvalent terms, however non-templates can also be incomplete:

struct X; /* incomplete */
struct x {}; /* complete */

Rob.