Re: using vector to encapulate a tree - non const copy constructors
terry wrote:
Repost as the original (13th Oct) did not appear on the site.
Hi, I have a problem with the way some implimentations of vector and other
stl containers refuse to use non-const contructors. My question is - is
the way they function the correct interpretation of the standard - and
if so
why.
MOTIVATION
The following data structure
class mytree: public T, protected std::vector<mytree>{};
This comes up pretty often: vector<> requires a complete type as parameter
but 'mytree' above is not a complete type.
The problem for me is that, for efficiency, one needs a non-const version
of the assignment and copy constructors. Everyone expects the constructor
mytree(const mytree & rhs)
to be defined, and of course it must do a deep copy, perhaps based on
using std::vector::assign. But one also really needs
mytree(mytree & rhs)
where the constructor copies the T object and swaps the container content
from the rhs into the lhs and so moves the whole tree just by moving the
root.
I don't follow you. A constructor that in fact swaps with the object it was
passed makes very limited sense. Using this as addition to one that does a
copy is just dangerous, consider this code:
yourtree t2(this->t1);
Does this copy or swap? Answer is that you can't tell, because you'd need
the context of the memberfunction (i.e. whether it is const or not) to
determine that. Such extreme differences depending on innocent changes are
a recipe for disaster.
In case you only want to avoid copying, you might consider implementing
semantics similar to std::auto_ptr or maybe create something like the MOJO
framework (search the web for it). Otherwise, an explicit swap()
memberfunction is also possible.
PROBLEM
My problem is that it seems that whenever a controlled sequence is copied
or moved to a new location by the stl container implimentations in
microsoft or g++ configurations the code seems to convert the objects to
be copied to const
reference types before calling the copy constructor.
This is, in my view, a bad decision, as I believe that it is up to the
input_iterator pointing to the data to be moved to decide whether the
controlled sequence is const and then C++ should choose the constructor
appropriately to match the signature presented.
No, sorry. The containers assume value semantics, which is also the reason
why e.g. std::auto_ptr is not suitable for storage in such a container.
Value semantics mean that copying does not modify the former value.
Uli
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]