Re: container traits
kanze wrote:
Jens Theisen wrote:
Greg Herlihy wrote:
Both compilers should accept this code - there is nothing
undefined about it at all. The tlist_iterator typedef is
neither an explicit instantiation nor a specialization of
std::list::iterator
Do you know where the requirement of list being instantiable
with incomplete T is in the standard? It should be somewhere.
?17.4.3.6/2: "In particular, the effects are undefined in the
following cases: [...] -- if an incomplete type is used as a
template arugment when instantiating a template component."
Declaring an empty, derived class of T would be an obvious
"workaround". There is no question that T is complete in the program
below. But it should just as clear that the program's behavior is
indistinguishable from the original. After all, a program's behavior is
affected soley by the instructions it executes and the data it
processes. Instantiating std::list<T> (or any template class) creates
neither code nor data. And there cannot be undefined behavior when
there is no behavior at all.
#include <list>
struct T { int x; };
template <class Type>
struct SelfIter : public Type
{
SelfIter() : Type() {}
typename std::list<Type>::iterator mIterator;
};
int main()
{
SelfIter<T> ti;
std::list<T> tList;
// insert ti in list while storing its iterator
ti.mIterator = tList.insert( tList.begin(), ti);
}
The code you posted is illegal, and at least one
compiler/library implemenation rejects it.
I would note that gcc's -D_GLIBCXX_CONCEPT_CHECK will reject any
program that so much as declares a std::list<T>. A concept check tests
a template class for its completeness - it does not test a program for
its correctness. In fact, a concept check essentially does nothing more
than declare a complete, explicit instantiation of std::list<T> like
so:
template class std::list<T>;
and with the same, predictable results. As a test, a concept check is
useful (and is in fact intended only for) a person actually writing a
template class library. For any other type of programming, the types of
"failures" reported - such as the fact that T does not implement either
a < or a == operator are simply not relevant. A program that never
compares or sorts T objects and never calls any method in std::list
that does - has no reason (and certainly no obligation) to overload
those operators in T.
Greg
---
[ 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 ]