It's interesting to know why uninitialized_copy()'s counterpart - uninitialized_move() - is missing in http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_uninitialized.h?revision=177542&view=markup ? See boost's docs for details - http://www.boost.org/doc/libs/1_48_0/doc/html/boost/uninitialized_move.html .
Because it's non-standard
It looks like it would be equivalent to uninitialized_copy with make_move_iterator, not so useful then.
(In reply to comment #2) > It looks like it would be equivalent to uninitialized_copy with > make_move_iterator, not so useful then. This makes sense, but not so obvious for novices in C++11. If continuing in this vein, then std::move() can be substituted by std::copy() with input iterator wrapped into make_move_iterator(). Then std::move() is not so useful :)
Marc gave you an important practical advice and rationale, but as matter of principle is more important that the function is *non standard*, really if you use that you are *outside* the new C++11 Standard, is that clear? And the name isn't uglified thus even if we wanted we could not add it and remain conforming. This issue is invalid.
(In reply to comment #3) > (In reply to comment #2) > > It looks like it would be equivalent to uninitialized_copy with > > make_move_iterator, not so useful then. > > This makes sense, but not so obvious for novices in C++11. I don't think novices should use anything with "uninitialized" in the name. Notice that very few functions on iterators have a move version. vector::insert doesn't come with a move_insert counterpart. > If continuing in this vein, then std::move() can be substituted by std::copy() > with input iterator wrapped into make_move_iterator(). True, although there can be subtle differences for input iterators where the reference type is not a reference to the value_type (there's a DR about that). > Then std::move() is not so useful :) Indeed. The standard tries to keep a balance, and I guess move was considered common enough to deserve its own interface, but could easily have been removed. Note that I don't think gcc's bugzilla is the best place for such discussions...