Template code works with g++ but not MSVC++

[Pierre-Marc Fournier]

The following code:

class ABC
{
std::list<ABC> mylist;
};

compiles in g++ without a problem. However, VC++ version 6 (latest service
pack), complains about the class ABC not being defined on the line where the
list is declared.

I tried adding a

class ABC;

statement before the class definition, but it had no effect. I understand
this problem is due to the fact that the template parameter of mylist is in
fact the class of which mylist is a member.

Is this a problem in microsoft's implementation, or is this normal behaviour
and the fact g++ accepts it is an extension? Are there any simple
workarounds? I need to get this code to work with both compilers.

Thanks
Pierre

 

[Alf P. Steinbach]

* Pierre-Marc Fournier:

The following code:

class ABC
{
std::list<ABC> mylist;
};

compiles in g++ without a problem. However, VC++ version 6 (latest service
pack), complains about the class ABC not being defined on the line where the
list is declared.

I tried adding a

class ABC;

statement before the class definition, but it had no effect. I understand
this problem is due to the fact that the template parameter of mylist is in
fact the class of which mylist is a member.

Is this a problem in microsoft's implementation

In VC6, yes. It only supports the most rudimentary features of templates.

I need to get this code to work with both compilers.

Indirection is the solution to every computer science problem.

 

[P.J. Plauger]

* Pierre-Marc Fournier:

In VC6, yes. It only supports the most rudimentary features of templates.

Bullshit. The C++ Standard requires that the element type for
any STL container be a complete type. You can get away with
an incomplete type if the library cuts corners on its
implementation of template class allocator, but don't count
on it.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[tom_usenet]

The following code:

class ABC
{
std::list<ABC> mylist;
};

compiles in g++ without a problem. However, VC++ version 6 (latest service
pack), complains about the class ABC not being defined on the line where the
list is declared.

I tried adding a

class ABC;

statement before the class definition, but it had no effect. I understand
this problem is due to the fact that the template parameter of mylist is in
fact the class of which mylist is a member.

Yes, inside the definition of ABC, ABC still has incomplete type.

Is this a problem in microsoft's implementation, or is this normal behaviour
and the fact g++ accepts it is an extension?

The latter; officially it is undefined behaviour. This particular
brand of undefined behaviour usually means it either works as you
expect, or you get a compiler error, depending on your
compiler/library combo.

Are there any simple
workarounds? I need to get this code to work with both compilers.

I note it seems to work with later versions of Dinkumware's library
(VC7+). The simplest workaround is to use
class ABC
{
std::list<ABC>* mylist;
};
since that doesn't instantiate std::list<ABC>, and doesn't require too
much housekeeping. std::list<ABC*> is an alternative, but that is much
more of a pain. shared_ptr<std::list<ABC> > is obviously the best bet.

Tom

 

[Alf P. Steinbach]

* P.J. Plauger:

Bullshit.

Sniff.

But language apart, which claim is it that in your opinion is "bullshit"?

Is it that you don't agree this particular problem is a problem in VC6?

That may be right, may be not, but it compiles with Comeau in strict mode,
so do you have, uh, chapter and verse here?

Is it that you don't agree VC6 only supports rudimentary features of
templates? If so, then that _is_ the word you used. Begging your pardon.

 

[P.J. Plauger]

Sniff.

But language apart, which claim is it that in your opinion is "bullshit"?

Is it that you don't agree this particular problem is a problem in VC6?
Yes.

That may be right, may be not,

It is right. See below.

but it compiles with Comeau in strict mode,

Just because something compiles with a given compiler/library
combination doesn't mean it's conforming. In this case, much
depends on how accommodating template class allocator happens
to be. Some older ones are accommodating because they themselves
don't conform; some newer ones are because they go out of their
way to permit this extension.

so do you have, uh, chapter and verse here?

From microsoft.public.vc.language, courtesy of Igor Tadnetik:

: C++ standard 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.
:
: Your program invokes undefined behavior. It may work with some STL
: implementations but not others.
: --
: With best wishes,
: Igor Tandetnik

Is it that you don't agree VC6 only supports rudimentary features of
templates?

"Rudimentary" is, of course, a qualitative judgement. VC6 does not
support template partial specialization and export templates. In
its earliest days it got member templates wrong, but that got fixed
with service packs. There are one or two other problems as well.
Nevertheless, its template support is rich enough to support STL
well enough that people hit its limitations only occasionally.

Still, I wasn't complaining about your use of the word "rudimentary".

If so, then that _is_ the word you used. Begging your pardon.

Begging yours, but I aimed the word at your from-the-hip assertion
that this was a "problem with Microsoft's implementation" in VC6.
It isn't.

HTH,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Alf P. Steinbach]

* P.J. Plauger:

It is right. See below.

I agree, tentatively at least, but this is a subtle issue.

I do not think me being wrong about that qualified for the wording
you used.

It would have been different coming from e.g. me ( ), but you
are the recipient of Dr Dobbs' award something-or-other, and generally
about as well-known as Bjarne, at least in the hard-core C++ community.

From microsoft.public.vc.language, courtesy of Igor Tadnetik:

: C++ standard 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.

§9.2/2 defines the detailed rules for where & when a class is regarded as
complete type versus incomplete type, it's not 100% simple.

And I'm not quite sure how the the standard allows constructs like
'class T: Base_<T>', when Base_<T> uses functions in T -- that it
does allow it is clear since this is very common, but not quite how; this
might seem irrelevant but was part of my belief support, so a
clarification here might be very helpful.