Re: [lmi] [lmi-commits] master ad8e4f7 3/3: Rework 7702 calculations

[Greg Chicares]

On 5/22/21 8:08 PM, Vadim Zeitlin wrote:
> On Sat, 22 May 2021 13:57:06 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> branch: master
> GC> commit ad8e4f74085a2697b0838df8581ab5fa2a9082ea
> GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> 
> GC>     Rework 7702 calculations
> GC>     
> GC>     Chose to hold a gpt7702 object in a std::shared_ptr rather than in a
> GC>     std::unique_ptr: it's notionally unique, but std::unique_ptr requires
> GC>     an explicit dtor, which isn't a good enough reason to write one.
> 
>  I wonder if this could be a good reason to add some impl_ptr<> class that
> would allow defining a unique owning pointer even to an object of an
> incomplete type, using the same technique as shared_ptr<> uses (i.e.
> storing a type-erased deleter), but without actually allowing sharing.

Sure. There's a sketch here:
  
https://stackoverflow.com/questions/9954518/stdunique-ptr-with-an-incomplete-type-wont-compile/48768924#48768924
That's not ideal (macros!), nor is it the best online discussion
that can be found--it's just something I happened to have open
in my browser.

I suppose we'd also want a corresponding make_unique<>() analog.

>  For me personally defining the dtor explicitly doesn't seem to be a big
> (or even noticeable) price to pay for just using unique_ptr<>, but if it's
> really so problematic, using a dedicated class would seem to be much better
> than allowing sharing the ownership of an object which is not supposed to
> be shared.

Yours is definitely the majority opinion. But to me, this just
seems horribly wrong: if I've designed a class that's already
perfect, why should I have to mangle it to accommodate some
obscure quirk of std::unique_ptr, writing a dtor that I don't
want, and polluting the physical design with #includes that
are not necessary for any purpose but this?

Protecting myself against sharing the ownership of an object
that I'm never going to share has some theoretical value, but
not enough to justify paying this unique_ptr tax.

>  Please let me know if you think it would be worth pursuing this further,

Sure. I'd rather use non-sharable smart pointers by default.
I just balk at paying a tax each time I do. If you can pay it
for me, up front, once and forever, then we'll both be happy.