Date: Tue, 4 May 2021 20:37:35 +0300
On 04/05/2021 20.30, Arthur O'Dwyer via Std-Proposals wrote:
> On Mon, May 3, 2021 at 5:22 AM Rick de Water via Std-Proposals
> <std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>> wrote:
>
> 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 size);
> 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::construct_at(T*, Args...)
> std::destroy_at(T*)
> std::uninitialized_default_construct(T* first, T* last);
> std::destroy(T*, T*)
> std::uninitialized_copy(T*, T*, T*);
> std::uninitialized_move(T*, T*, T*);
>
> Are you familiar with P1144 "Object relocation in terms of
> move+destroy"? It adds:
> std::relocate_at(T*, T*);
> std::uninitialized_relocate(T*, T*, T*);
>
> P1144 is stationary in the water at the moment; I've got a draft
> D1144R6 at
> http://quuxplusone.github.io/draft/d1144-object-relocation.html
> <http://quuxplusone.github.io/draft/d1144-object-relocation.html>
> 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
> https://p1144.godbolt.org/z/nxdWGxj5M
> <https://p1144.godbolt.org/z/nxdWGxj5M>
> 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).
That is very sad to hear, my code could certainly use the proposal. But
I'm not desperate enough to use a patched compiler (the vanilla version
is plenty broken already).
> On Mon, May 3, 2021 at 5:22 AM Rick de Water via Std-Proposals
> <std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>> wrote:
>
> 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 size);
> 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::construct_at(T*, Args...)
> std::destroy_at(T*)
> std::uninitialized_default_construct(T* first, T* last);
> std::destroy(T*, T*)
> std::uninitialized_copy(T*, T*, T*);
> std::uninitialized_move(T*, T*, T*);
>
> Are you familiar with P1144 "Object relocation in terms of
> move+destroy"? It adds:
> std::relocate_at(T*, T*);
> std::uninitialized_relocate(T*, T*, T*);
>
> P1144 is stationary in the water at the moment; I've got a draft
> D1144R6 at
> http://quuxplusone.github.io/draft/d1144-object-relocation.html
> <http://quuxplusone.github.io/draft/d1144-object-relocation.html>
> 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
> https://p1144.godbolt.org/z/nxdWGxj5M
> <https://p1144.godbolt.org/z/nxdWGxj5M>
> 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).
That is very sad to hear, my code could certainly use the proposal. But
I'm not desperate enough to use a patched compiler (the vanilla version
is plenty broken already).
Received on 2021-05-04 12:37:40