Re: [ boost.out_ptr ] [ Review Endorsement ] New Library targeting C++11

From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2019-06-02 02:08:28

Dear Gavin Lambert and Andrzej Krzemienski,

     I have updated the destructors documentation and implementation to
reflect noexcept-ness of the operations it wraps:
https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/reference/out_ptr.adoc#destructors
.

    Hilariously, doing this has caused MSVC 2015 to roll over and C1001
itself from all the noexcept specifications.

Sincerely,
JeanHeyd

On Wed, May 29, 2019 at 6:26 PM JeanHeyd Meneide <phdofthehouse_at_[hidden]>
wrote:

> On Wed, May 29, 2019 at 12:23 PM Zach Laine via Boost <
> boost_at_[hidden]> wrote:
>
>> On Wed, May 29, 2019 at 11:09 AM Andrzej Krzemienski via Boost <
>> boost_at_[hidden]> wrote:
>>
>> > It is my understanding that the library has been first submitted for
>> > standardization, and accepted by LEWG. The potential Boost review will
>> take
>> > place after it has been accepted to the C++ Standard Library. Or am I
>> > missing something?
>> >
>> > Regards,
>> > &rzej;
>> >
>>
>> Well, there is a pretty long process between now and a final C++20
>> standard, including National Body comments and their resolutions.  If we
>> review out_ptr soon enough, we can still use that feedback.  The usable
>> feedback effectively only applies to fixing problems, not tweaks in the
>> design.  After C++20 finally ships, we're stuck -- even if we find big and
>> easy-to-fix problems.
>>
>> Zach
>>
>
> The library was actually submitted for Boost first before the making it to
> LWG, given that was part of the feedback from the first time it was
> reviewed in San Diego. It was discussed at the Boost Dinner to put the type
> through the Boost Review process, but to also consider putting it in a
> pre-existing library (boost.movelib and boost.smart_ptr). I chose the
> pre-existing library route, but given design decision and time constraints
> was encouraged to submit it as an independent library instead. Had the
> earlier routes (pre-existing libraries) been deemed appropriate, this would
> have been in Boost by 1.70, before being forwarded to LWG.
>
> The good news is, LEWG has control over the design of the thing: CTAD
> versus no CTAD, factory functions, customization point design, etc.: all of
> that is fine and should be staying the same barring a catastrophe. What's
> up in the air is the exact wording of the specification, which I believe a
> Review will be incredibly helpful with.
>
> Gavin Lambert:
>
>      The implementation (and wording on the reference docs and reference
> paper) were scaled back to always initialize `p` with its value
> initialization and not to allow for any optimizations. I suspect this might
> be a sticking point for some who have APIs that take care of setting the
> nullptr for them, and they would likely benefit from a performance using
> out_ptr that aliases / reseats the pointer directly (as my implementation
> had been doing to gain performance benefits in the benchmarks over the
> "simple out_ptr" benchmark case). The good news is, nothing about this
> precludes boost (or the Standard) from creating a new factory function or
> type in the case where the user holds certain expectations over the
> function call they are using. My current thought is that maybe a tag type /
> tag object going as the first argument can help indicate that it is
> "non-nullptr safe"... but that's more design that lies outside the scope of
> this proposal and review.
>
> Sincerely,
> JeanHeyd Meneide
>