Home > Archive > VC STL > March 2005 > std::list problem
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Heinz Ozwirk 2005-03-17, 9:00 pm |
| The following class definition does not compile:
#include <list>
#include <vector>
class Foo
{
std::list<Foo> aList;
std::vector<Foo> aVector;
};
The definition of aList failes with
"error C2079: 'std::_List_nod<_Ty,_Alloc>::_Node::_Myval' uses "
"undefinierted class 'Foo'"
The definition of aVector, however, compiles without any problems. I =
would expect both to compile or both to fail, but what does the standard =
say about it? Should the both compile or both fail? Has this problem =
been fixed since the release of VS 7.0?
tnx
Heinz
| |
| Bo Persson 2005-03-17, 9:00 pm |
|
"Heinz Ozwirk" <hozwirk.SPAM@arcor.de> skrev i meddelandet
news:4239f27d$0$1091$9b4e6d93@newsread2.arcor-online.net...
> The following class definition does not compile:
>
> #include <list>
> #include <vector>
>
> class Foo
> {
> std::list<Foo> aList;
> std::vector<Foo> aVector;
> };
>
> The definition of aList failes with
>
> "error C2079: 'std::_List_nod<_Ty,_Alloc>::_Node::_Myval' uses "
> "undefinierted class 'Foo'"
>
> The definition of aVector, however, compiles without any problems. I
> would expect both to compile or both to fail,
> but what does the standard say about it? Should the both compile or
> both fail? Has this problem been fixed since
> the release of VS 7.0?
>
> tnx
> Heinz
The standard just says that you should get a diagnostic if your program
contains certain errors. You did.
It doesn't say that you should get exactly two messages if you make two
errors.
Bo Persson
| |
| Carl Daniel [VC++ MVP] 2005-03-17, 9:00 pm |
| "Heinz Ozwirk" <hozwirk.SPAM@arcor.de> wrote in message
news:4239f27d$0$1091$9b4e6d93@newsread2.arcor-
> The definition of aVector, however, compiles without any problems.
> I would expect both to compile or both to fail, but what does the
> standard say about it? Should the both compile or both fail?
> Has this problem been fixed since the release of VS 7.0?
Your expectations would be wrong, however. It's not legal to instantiate
any of the standard containers on an incomplete type - there's no
requirement that it either succeed or fail. There's nothing to fix - the
behavior is within the lattitude allowed by the standard.
-cd
| |
| John Carson 2005-03-18, 4:01 am |
| "Carl Daniel [VC++ MVP]"
<cpdaniel_remove_this_and_nospam@mvps.org.nospam> wrote in message
news:ec3iTgzKFHA.1992@TK2MSFTNGP15.phx.gbl
> "Heinz Ozwirk" <hozwirk.SPAM@arcor.de> wrote in message
> news:4239f27d$0$1091$9b4e6d93@newsread2.arcor-
>
> Your expectations would be wrong, however. It's not legal to
> instantiate any of the standard containers on an incomplete type -
> there's no requirement that it either succeed or fail. There's
> nothing to fix - the behavior is within the lattitude allowed by the
> standard.
> -cd
Agreed. But, as it happens, VC++ 7.1 does compile the code supplied by the
OP.
--
John Carson
| |
| Carl Daniel [VC++ MVP] 2005-03-18, 4:01 am |
| John Carson wrote:
>
> Agreed. But, as it happens, VC++ 7.1 does compile the code supplied
> by the OP.
Pitty.
-cd
| |
| John Carson 2005-03-18, 4:01 am |
| "Carl Daniel [VC++ MVP]"
<cpdaniel_remove_this_and_nospam@mvps.org.nospam> wrote in message
news:Oxm%23SC2KFHA.2648@TK2MSFTNGP14.phx.gbl
> John Carson wrote:
>
> Pitty.
>
> -cd
I am not so sure. This has been discussed several times on comp.lang.c++ and
the corresponding moderated newsgroups. Section 14.3.1/2 of the C++ standard
says that a template type argument may be an incomplete type. On the other
hand, section 17.4.3.6 says that standard containers are not required to
accept incomplete types when instantiating a template component.
My recollection of the newsgroup discussion is that, at the time the
standard was formulated, it was not known to what extent it was technically
feasible to allow incomplete types in containers. It subsequently proved to
be possible to a greater extent than the pessimists believed. Since it is a
convenient feature, there is some talk that it will become part of the
standard in the future. See, for example, the following post by Jonathan
Turkanis.
http://groups-beta.google.com/group...215af7cd0c7f226
--
John Carson
| |
| Mycroft Holmes 2005-03-18, 8:58 am |
| In article <ewyXeV1KFHA.3376@TK2MSFTNGP10.phx.gbl>,
"John Carson" <jcarson_n_o_sp_am_@netspace.net.au> wrote:
>
>
> Agreed. But, as it happens, VC++ 7.1 does compile the code supplied by the
> OP.
that's because usually std::vector<T> holds a T* member, so to compile
it (without accessing members) it is sufficient to know that T is a
type, complete or incomplete.
std::list instead holds a T member in each node, so T must be complete.
It is somehow surprising that it's illegal to instantiate vector<T> with
incomplete T, because it contradicts the general rule "use a vector to
avoid a new[] statement".
--
The set of solutions is never empty.
Two solutions together form a new problem.
-- Mycroft Holmes
| |
| Tom Widmer 2005-03-18, 8:58 am |
| Mycroft Holmes wrote:
> In article <ewyXeV1KFHA.3376@TK2MSFTNGP10.phx.gbl>,
> "John Carson" <jcarson_n_o_sp_am_@netspace.net.au> wrote:
>
>
>
>
> that's because usually std::vector<T> holds a T* member, so to compile
> it (without accessing members) it is sufficient to know that T is a
> type, complete or incomplete.
> std::list instead holds a T member in each node, so T must be complete.
Yes, but the node type need not be complete to declare a std::list (if
the implementation is written in the right way), certainly not if
std::allocator is the allocator.
> It is somehow surprising that it's illegal to instantiate vector<T> with
> incomplete T, because it contradicts the general rule "use a vector to
> avoid a new[] statement".
The standard should probably be changed for vector at a minimum, and
possibly for some other container types as well.
Tom
| |
| John Carson 2005-03-18, 4:03 pm |
| "Mycroft Holmes" <m.holmes@nospam.it> wrote in message
news:m.holmes-21110F.11571518032005@msnews.microsoft.com
> In article <ewyXeV1KFHA.3376@TK2MSFTNGP10.phx.gbl>,
> "John Carson" <jcarson_n_o_sp_am_@netspace.net.au> wrote:
>
>
> that's because usually std::vector<T> holds a T* member, so to compile
> it (without accessing members) it is sufficient to know that T is a
> type, complete or incomplete.
> std::list instead holds a T member in each node, so T must be
> complete.
Since the code also compiles for the list container, the second half of your
statement does not appear to be completely correct.
--
John Carson
| |
| Mycroft Holmes 2005-03-18, 4:03 pm |
| In article <eBtE6L7KFHA.3380@TK2MSFTNGP15.phx.gbl>,
Tom Widmer <tom_usenet@hotmail.com> wrote:
>
> Yes, but the node type need not be complete to declare a std::list (if
> the implementation is written in the right way), certainly not if
> std::allocator is the allocator.
>
actually, in VC 7.1 the original example compiles.
--
The set of solutions is never empty.
Two solutions together form a new problem.
-- Mycroft Holmes
|
|
|
|
|