Re: rvalue containers - more problems
Am 11.04.2012 18:55, schrieb Ulrich Eckhardt:
on Mon Apr 09 2012, Gene Bushuyev<publicfilter-AT-gbresearch.com>
wrote:
This time I stumbled upon a problem using rather common
std::set<std::string> container when I needed to move a large set
of strings to another container. As far as I can see, there is no
way to move strings from the set, because set provides only const
iterator. There are no functions in the set class which would
allow moving either whole set or an iterator range to another
container.
[..]
If I understand the OP correctly, then he meant something like
std::list's splice() function.
splice only allows "moving" nodes between the same container type, but
the OP's description clearly (at least to me) ask for transferal to
"another container". This cannot be realized by splice and
friends. IMO one of the most promising directions would be Howard
Hinnant's idea expressed in
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839
where node_ptr represents a mutable and isolated node element. One
could move-out the actual key from this node or modify it
otherwise. This would effectively allow to move key-by-key from a set
to any other container.
I see no fundamental reason that this couldn't be implemented for
[multi]{set,map}.
One drawback though is that this would either unbalance the internal
tree structure or require possibly expensive rebalancing. Also, it
suddenly exposes implicitly that the internal structure is a tree
made up of separate nodes, which is not guaranteed. I could well
imagine the nodes being held in a vector with indices replacing the
pointers of a "normal" tree.
Either I misunderstand your imagined implementation or it seems
impossible (at least beyond reasonable overhead) to implement that
way.
How do you ensure the special requirements on insert (emplace) and
erase:
"The insert and emplace members shall not affect the validity of
iterators and references to the container, and the erase members shall
invalidate only iterators and references to the erased elements."
Note that it also gives a this guarantee for references, so even if
you would like to pack something into a vector (which at some point
must grow), this object must somehow behave like a "node".
Greetings from Bremen,
Daniel Kr??gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]