Subject: Re: [std-proposals] item_traits: A simple solution for destructive move
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2021-05-04 12:30:08
On Mon, May 3, 2021 at 5:22 AM Rick de Water via Std-Proposals <
> When working on a container library I needed to manage the complexity of
> moving items around (memcpy when trivial, noexcept or not, copy if not
> movable, etc), and I came up with a traits class that manages everything
> for you. You give it a destination pointer, and often a source pointer, and
> the traits class will do the rest.
> This is already very useful to have, but then I realized that it could
> also easily do a destructive move. By specializing the traits class for a
> destructively movable item (like unique_ptr) it can optimally move the
> items from the source to the destination memory. All container classes can
> then simply use item_traits to move items around whenever needed.
> Here is a simplification of my current implementation:
> template <typename Item>
> struct item_traits
> using value_type = Item;
> using pointer = value_type*;
> using const_pointer = const value_type*;
> using size_type = std::size_t;
> static void construct(pointer destination, size_type size);
> static void destruct(pointer destination, size_type size);
> static void copy(pointer destination, const_pointer source, size_type
> static void move(pointer destination, pointer source, size_type size);
> static void destructive_move(pointer destination, pointer source,
> size_type size);
Are you familiar with the existing STL free functions for these operations?
std::uninitialized_default_construct(T* first, T* last);
std::uninitialized_copy(T*, T*, T*);
std::uninitialized_move(T*, T*, T*);
Are you familiar with P1144 "Object relocation in terms of move+destroy"?
std::uninitialized_relocate(T*, T*, T*);
P1144 is stationary in the water at the moment; I've got a draft D1144R6 at
but I don't see it going anywhere at WG21 without compiler vendor buy-in,
and I don't see it going anywhere with compiler vendors without WG21 buy-in.
What it really needs is for someone *in industry* to start using my patched
version of Clang+libc++, visible at
and maintained on my GitHub; and then crowing about how cool it is (or,
perhaps, realizing it's not so cool â we simply don't know yet because
nobody's really tried it out).
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups