Re: Yet Another Container: DynamicArray

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-01-29 18:49:35

On Wed, Jan 29, 2020 at 4:22 AM Gavin Lambert via Boost <
boost_at_[hidden]> wrote:

> At 19:02 29/01/2020, Glen Fernandes wrote:
>  >You shouldn't expect that. For any unique_ptr<T, D> you can only
>  >expect that .get() gives you a D::pointer. For default_delete<T>
>
>  >this might be T*.  But it always depends on the Deleter.
>
> That seems like a significantly more annoying interface than
> std::shared_ptr uses.
>
> shared_ptr can hold fancy pointers too, but it happens explicitly
> via using fancy<T> rather than plain T, so the explicit
> indirection on usage is obvious too.
>
> Having that be an implementation detail of the deleter changing
> the effective "type" of the first template argument (which is what
> people think of as the type of the pointer, even if the standard
> disagrees) seems quite annoying.
>
> Maybe we should have a type-erased unique ownership pointer as
> well.  I know the reason why we didn't was to avoid heap
> allocation or wasted storage for the common case, but there ought
> to be some happy middle ground.

What you're describing is shared_ptr with the copy ctor deleted and a move
ctor that swaps with the source or some such. You'll pay for the storage
and the initialization of the refcounters but that's probably negligible.
We just need someone from WG21 to take a stab at implementing it to compare
its performance to shared_ptr, on single-threaded Windows. :)