Re: container traits
Jens Theisen wrote:
Greg Herlihy wrote:
Furthermore, the T class can be just as easily implemented without a
typedef:
#include <list>
struct T
{
std::list<T>::iterator mIter;
};
Undefined behaviour as well, unless there is a guarantee in
the standard that says otherwise. If std::list does something
like the following Foo
template< class T >
struct Foo
{
enum { s = sizeof(T) };
};
the above example will fail. If kanze is right, then an
implementation is allowed to do that - though admittedly, I
can't see a reason why it should.
In more than a few cases, the standard takes a simple approach.
Rather than trying to specify exactly what can and cannot be
instantiated with an incomplete type, it says that it is
undefined behavior to instantiate ANY template in the standard
library with an incomplete type. In practice, I can't see a
real need for not supporting it for any of the standard
containers, but the author's of the standard chose not to go
into detail.
(Wisely, IMHO. At the time the standard was being finalized, we
lacked much real experience with most of the standard library.
In such cases, it is almost always preferrable to be
conservative; it's easier to make undefined behavior defined in
a later version of the standard, than vice versa.)
In other words an class object would not be able to hold a
shared pointer to its own type.
It's one of the distinct features of shared_ptr that it's
pointee may be incomplete at any time but construction.
It's all a question of contract. The author's of the smart
pointers in Boost decided to guarantee certain things which
aren't guaranteed for the templates in the standard library. If
anyone felt it worthwhile to write up a proposal, I imagine that
the library committee would be willing to consider increasing
the guarantees for standard classes in the next version of the
standard. I could see, for example, not requiring assignable
for std::list (while still requiring it for the other
collections), or not requiring a complete type to instantiate
one of the standard container (while requiring it for any
function in the container). Whether such reduced instructions
are worth the bother or not, I don't know; I think it might be
useful to allow a class to contain a container of its types.
But of course, if no one takes the time to actually write up a
proposal, it isn't going to happen. (From what I've seen, the
people actively working in the library group aren't lacking in
things to do.)
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]