Re: using vector to encapulate a tree - non const copy constructors
terry wrote:
I dont understand your comments or those of Ulrich.
The syntax
class T : public: mytemplate<T>
can be perfectly correct C++.
The syntax is perfectly correct. Whether the code is otherwise
legal depends on the constraits on the type for mytemplate. If,
for example, one of the constraints is that it be an arithmetic
type, then of course, you've violated a constraint, which is
typically undefined behavior.
One of the constraints on the first parameter of std::vector
(and in fact, on all type parameters of all templates in the
standard library, at present) is that it be a complete type at
the point of instantiation. And the standard explicitly says
that violating this constraint is undefined behavior. (Better
libraries are gradually moving to make violations of these
constraints compile time errors, and there is significant
activity within the standards committee to improve the detection
of constraints violations.)
Indeed is widely used and the only way to
do certain things. My declaration
class mytree: public T, protected std::vector<mytree>{};
compiles perfectly on all compilers I try,
It doesn't compile with g++, at least not since 4.0. And the
fact that something happens to compile with a particular
compiler doesn't prove that there is no undefined behavior.
and is, I think, completely correct C++.
You're wrong.
The current version of the standard is probably stricter than
necessary, there are definitly arguments for not requiring a
complete type for e.g. smart pointers, and the next version of
the standard will have exceptions to the rule that a complete
type is required (for shared_ptr, at least). But as far as I
know, there has been no proposition to remove this requirement
from the standard containers.
It is fully formed (has a size), and not self referential.
Maybe. The standard doesn't require this of an implementation.
You're code violates a constraint on the instantiation type; the
result is undefined behavior.
The object vector<A> does not contain any object
of type A and should be regarded as similar to a collection of (as yet
unassigned) pointers of type A*.
Maybe. An object of vector<A> is certainly allowed to contain
such an object, or otherwise use expressions which require a
complete type. Although I consider it highly unlikely in the
case of vector, the standard certainly allows the equivalent of
the small string optimization, where the vector contains a
buffer for a small number of objects, and uses it, rather than
dynamically allocated memory, as long as the vector is small
enough. (Such a buffer would be declared using "unsigned char
buf[ N*sizeof(A) ]".)
The same sort of object as you would
use if you were constructing a tree by hand.
The declaration really does encapulate a tree and can (I have) be used
effectively. I really don't agree that it is erroneous - it is there!
So you have a program which depends on undefined behavior, and
just happens to work with the compiler you are currently using.
It won't compile with the latest versions of g++.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]