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

newer
Re: [boost] [Boost.Config] Detect...

older
Re: [boost] [Boost.Config] Detect...

JeanHeyd Meneide

27 May 2019 27 May '19

6 a.m.

Dear Boost Community, After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc -- targeting C++11 -- to be endorsed for review. Documentation: ascii doc-ready and readable on GitHub https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: GitHub https://github.com/ThePhD/out_ptr Standards Proposal: p1132 https://thephd.github.io/vendor/future_cxx/papers/d1132.html (accepted for and targeting C++20) boost.out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt-into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc and the Standard C++ proposal https://thephd.github.io/vendor/future_cxx/papers/d1132.html#perf for more details). Many thanks to the in-person discussion during Library in a Week at C++Now, which helped shape the implementation and yield the final Rationale https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc. Many thanks to Ezra (eracpp) for a lot of the quick, easy-to-read examples that became part of the documentation. Sincerely, JeanHeyd Meneide

Show replies by date

Hans Dembinski

27 May 27 May

8:31 a.m.

Hi,

...

On 27. May 2019, at 08:00, JeanHeyd Meneide via Boost wrote:

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc -- targeting C++11 -- to be endorsed for review.

Documentation: ascii doc-ready and readable on GitHub https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: GitHub https://github.com/ThePhD/out_ptr Standards Proposal: p1132 https://thephd.github.io/vendor/future_cxx/papers/d1132.html (accepted for and targeting C++20)

this seems like a useful project, but reading the docs is frustrating. I find them less approachable than they should be. Here is some feedback: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc It should be explained what CTAD is and/or a link to its definition should be provided. Just dropping acronyms is bad. If the authors expect the user to read p1132, before reading this page, that should be stated here. I am also missing a simple and concise explanation what kind of behavior outptr implements. In p1132, it says in the abstract: "out_ptr is an abstraction to bring both C APIs and smart pointers back into the promised land by creating a temporary pointer-to-pointer that updates the smart pointer when it destructs." This abstract is not telling me what exactly outptr is doing. It "updates" the smart pointer, that's very vague, you can be specific. outptr is very simple, so it should be possible to explain its behaviour in one or two sentences. From looking at the examples, I deduce that it converts any smart pointer to the corresponding raw pointer that can be passed to the C API and calls "release()" on the resource on destruction. I can't find this simple statement neither in the rationale nor in the abstract of n1132. The section "Motivation" starts with an example, that's bad style. first give a bit of intro and then show the example. https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/overview.adoc This page is helpful, but the example should be cleaned of distracting stuff like ``` PWM_AXIS_ZERO, VLT_LOW_POW | VLT_POW_SAVE, 0x001B ``` A minimal example is: ``` boost::shared_ptr shared_resource_ptr; errno err = some_c_api(&shared_resource_ptr); if (err != SUCCESS) { // error handling code } ``` Best regards, Hans

JeanHeyd Meneide

9:43 a.m.

Dear Hans, Thank you for your feedback. I updated the documentation, top-level landing page, rationale and overview accordingly. Sincerely, JeanHeyd On Mon, May 27, 2019 at 4:28 AM Hans Dembinski wrote:

...

Hi,

...
On 27. May 2019, at 08:00, JeanHeyd Meneide via Boost < boost@lists.boost.org> wrote:

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc -- targeting C++11 -- to be endorsed for review.

Documentation: ascii doc-ready and readable on GitHub https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: GitHub https://github.com/ThePhD/out_ptr Standards Proposal: p1132 https://thephd.github.io/vendor/future_cxx/papers/d1132.html (accepted for and targeting C++20)

this seems like a useful project, but reading the docs is frustrating. I find them less approachable than they should be. Here is some feedback:

https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc

It should be explained what CTAD is and/or a link to its definition should be provided. Just dropping acronyms is bad. If the authors expect the user to read p1132, before reading this page, that should be stated here.

I am also missing a simple and concise explanation what kind of behavior outptr implements. In p1132, it says in the abstract:

"out_ptr is an abstraction to bring both C APIs and smart pointers back into the promised land by creating a temporary pointer-to-pointer that updates the smart pointer when it destructs."

This abstract is not telling me what exactly outptr is doing. It "updates" the smart pointer, that's very vague, you can be specific. outptr is very simple, so it should be possible to explain its behaviour in one or two sentences.

From looking at the examples, I deduce that it converts any smart pointer to the corresponding raw pointer that can be passed to the C API and calls "release()" on the resource on destruction. I can't find this simple statement neither in the rationale nor in the abstract of n1132.

The section "Motivation" starts with an example, that's bad style. first give a bit of intro and then show the example.

https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/overview.adoc

This page is helpful, but the example should be cleaned of distracting stuff like

``` PWM_AXIS_ZERO, VLT_LOW_POW | VLT_POW_SAVE, 0x001B ```

A minimal example is:

``` boost::shared_ptr shared_resource_ptr; errno err = some_c_api(&shared_resource_ptr); if (err != SUCCESS) { // error handling code } ```

Best regards, Hans

Gottlob Frege

9:18 p.m.

On Mon, May 27, 2019 at 4:29 AM Hans Dembinski via Boost wrote:

...

Hi,

...
On 27. May 2019, at 08:00, JeanHeyd Meneide via Boost wrote:

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc -- targeting C++11 -- to be endorsed for review.

Documentation: ascii doc-ready and readable on GitHub https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: GitHub https://github.com/ThePhD/out_ptr Standards Proposal: p1132 https://thephd.github.io/vendor/future_cxx/papers/d1132.html (accepted for and targeting C++20)

this seems like a useful project, but reading the docs is frustrating. I find them less approachable than they should be. Here is some feedback:

https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc

It should be explained what CTAD is and/or a link to its definition should be provided. Just dropping acronyms is bad. If the authors expect the user to read p1132, before reading this page, that should be stated here.

Get accustomed to this one, it goes along with SFINAE, RAII, and CPPIBAA (C++ Is Bad At Acronyms). Many docs probably skip explaining SFINAE or RAII, but CTAD is still new, so, yeah, it would be great to throw in the definition. Tony

Andrzej Krzemienski

12:20 p.m.

Hi JeanHeyd, Thanks for creating and sharing the library. I must admit that I followed it for a while, both in Boost and the LEWG proposal and I was never able to grasp what it is for. Now, this time, the docs seem to be a lot more clear. We have a good motivation page: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/overview.adoc I really appreciate it. The just edited initial page is helpful. I also recommend putting this text in the intro page: "the C++11 abstraction for passing smart pointers as parameters to T** arguments" -- it helped me a lot to understand what the library is for. And let me make sure if I actually grasped the scope of the library. Let me make an inverse statement. "Unless I am using APIs that take T**, this out_ptr will be of no use to me". Is this statement correct? I have one immediate comment. a lot of stuff is performed in the destructor of out_ptr_t: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/reference/out_ptr... In fact, it calls constructors of smart pointers (with custom deleters) that can potentially throw exceptions. This is disturbing that the destructor of out_ptr_t can silently throw an exception. And in such case, we do not know what happens. Your destructor is not marked `noexcept`: in the Standard Library it means it obtains `noexcept` silently. In Boost it means nothing special, so whether it is noexcept or not depends of the internal details of the class implementation, so you are recommended to declare explicitly either `noexcept` or `noexcept(false)`. Regards, &rzej; pon., 27 maj 2019 o 08:01 JeanHeyd Meneide via Boost napisał(a):

...

Dear Boost Community,

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc -- targeting C++11 -- to be endorsed for review.

Documentation: ascii doc-ready and readable on GitHub https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: GitHub https://github.com/ThePhD/out_ptr Standards Proposal: p1132 https://thephd.github.io/vendor/future_cxx/papers/d1132.html (accepted for and targeting C++20)

boost.out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt-into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks < https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc

...
...
. Many thanks to Ezra (eracpp) for a lot of the quick, easy-to-read examples

and the Standard C++ proposal https://thephd.github.io/vendor/future_cxx/papers/d1132.html#perf for more details). Many thanks to the in-person discussion during Library in a Week at C++Now, which helped shape the implementation and yield the final Rationale <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc that became part of the documentation.

Sincerely, JeanHeyd Meneide

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

JeanHeyd Meneide

2:28 p.m.

Dear Andrzej, Yes, the library is not of much use to people who do not have to deal with `T**`. When I initially wrote my own version of this abstraction over 6-7 years ago now believing it would only come up when I needed to talk to old APIs, a surprising amount of new code writes in this style for intialization of objects. The benefits of a stable C ABI, the idiomatic understanding for having an output T** with an error-return, and the power of COM are still compelling value-adds to a lot of libraries and it has surfaced again and again over the years. Regarding destructors: yes. In the standard library, we have implicit noexcept on destructors. This inherits that same noexcept guarantee and is how it is implemented both here and (soon) in the Standard, pending LWG approval. unique_ptr has a noexcept .reset(); shared_ptr does not (control block allocation may fail, etc.). However, other RAII types that wrap objects and call non-noexcept functions are marked noexcept themselves: e.g., lock_guard which calls mutex.unlock https://en.cppreference.com/w/cpp/thread/mutex/unlock. In practice, I have not seen this create issues. Sincerely, JeanHeyd Meneide On Mon, May 27, 2019 at 8:20 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...

Hi JeanHeyd,

Thanks for creating and sharing the library. I must admit that I followed it for a while, both in Boost and the LEWG proposal and I was never able to grasp what it is for.

Now, this time, the docs seem to be a lot more clear. We have a good motivation page: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/overview.adoc I really appreciate it. The just edited initial page is helpful. I also recommend putting this text in the intro page: "the C++11 abstraction for passing smart pointers as parameters to T** arguments" -- it helped me a lot to understand what the library is for.

And let me make sure if I actually grasped the scope of the library. Let me make an inverse statement. "Unless I am using APIs that take T**, this out_ptr will be of no use to me". Is this statement correct?

I have one immediate comment. a lot of stuff is performed in the destructor of out_ptr_t:

https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/reference/out_ptr...

In fact, it calls constructors of smart pointers (with custom deleters) that can potentially throw exceptions. This is disturbing that the destructor of out_ptr_t can silently throw an exception. And in such case, we do not know what happens. Your destructor is not marked `noexcept`: in the Standard Library it means it obtains `noexcept` silently. In Boost it means nothing special, so whether it is noexcept or not depends of the internal details of the class implementation, so you are recommended to declare explicitly either `noexcept` or `noexcept(false)`.

Regards, &rzej;

pon., 27 maj 2019 o 08:01 JeanHeyd Meneide via Boost < boost@lists.boost.org> napisał(a):

...
Dear Boost Community,

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc -- targeting C++11 -- to be endorsed for review.

Documentation: ascii doc-ready and readable on GitHub https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: GitHub https://github.com/ThePhD/out_ptr Standards Proposal: p1132 https://thephd.github.io/vendor/future_cxx/papers/d1132.html (accepted for and targeting C++20)

boost.out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt-into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks <

https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc

...
...
...
. Many thanks to Ezra (eracpp) for a lot of the quick, easy-to-read examples

and the Standard C++ proposal https://thephd.github.io/vendor/future_cxx/papers/d1132.html#perf for more details). Many thanks to the in-person discussion during Library in a Week at C++Now, which helped shape the implementation and yield the final Rationale < https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc that became part of the documentation.

Sincerely, JeanHeyd Meneide

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Gavin Lambert

11:57 p.m.

On 28/05/2019 02:28, JeanHeyd Meneide wrote:

...

Regarding destructors: yes. In the standard library, we have implicit noexcept on destructors. This inherits that same noexcept guarantee and is how it is implemented both here and (soon) in the Standard, pending LWG approval. unique_ptr has a noexcept .reset(); shared_ptr does not (control block allocation may fail, etc.). However, other RAII types that wrap objects and call non-noexcept functions are marked noexcept themselves: e.g., lock_guard which calls mutex.unlock https://en.cppreference.com/w/cpp/thread/mutex/unlock.

lock_guard is a "true" RAII type, though, and mutex unlock is an "destruction type" operation that should never actually fail even if the method was not explicitly marked noexcept. (Especially when interacting with legacy mutex types that might not indicate noexcept behaviour.) out_ptr is *not* an RAII type and its destructor has "non-destructive" side effects that are known to invoke memory allocation and construction, which are both exception-prone operations. I think it makes the most sense to declare it noexcept(false). Or possibly conditional noexcept on all the operations performed, so that as you say above, it would be noexcept for unique_ptr and not for shared_ptr. It's probably also worth adding to the caveats that the smart pointer must always be declared before and outside of the full-expression that contains the out_ptr. (While you'd normally expect this in order to achieve useful variable lifetime scoping, it would probably be possible to construct an example that does this incorrectly.) If they're in the same expression then it might be possible for the compiler to destroy the smart pointer before destroying the out_ptr, and then hilarity will ensue. Regarding the "poorly designed C APIs" caveat: some APIs guarantee that they do not alter the value of output parameters on failure. So you definitely should not assume that the value is always set to nullptr on failure; at least for out_ptr you should be passing in a raw pointer that is already nullptr, not uninitialised or some other value. If you're not doing that, the bug is in your library, not in the API. (Your caveat is correct for inout_ptr, however.)

Gottlob Frege

9:15 p.m.

On Mon, May 27, 2019 at 2:01 AM JeanHeyd Meneide via Boost wrote:

...

Dear Boost Community,

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc -- targeting C++11 -- to be endorsed for review.

Documentation: ascii doc-ready and readable on GitHub https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: GitHub https://github.com/ThePhD/out_ptr Standards Proposal: p1132 https://thephd.github.io/vendor/future_cxx/papers/d1132.html (accepted for and targeting C++20)

boost.out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt-into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc and the Standard C++ proposal https://thephd.github.io/vendor/future_cxx/papers/d1132.html#perf for more details). Many thanks to the in-person discussion during Library in a Week at C++Now, which helped shape the implementation and yield the final Rationale https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc. Many thanks to Ezra (eracpp) for a lot of the quick, easy-to-read examples that became part of the documentation.

Sincerely, JeanHeyd Meneide

+100 Remember the good ol' days when libraries went through Boost before getting into the standard? Well, in this case, maybe we still have time for at least concurrent Boost and standard acceptance. I really appreciate the input of the Boost review process. P.S. I also like this library :-) Tony

Louis Dionne

29 May 29 May

4:03 p.m.

Boost - Dev mailing list wrote

...

Dear Boost Community,

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc>; -- targeting C++11 -- to be endorsed for review.

[...]

I endorse the review of out_ptr. I think it's a great idea to get feedback from a Boost review before standardizing a library, and I wish more folks chose to go down that road. Thanks for doing your due diligence JeanHeyd, and I hope the Boost review can gather useful feedback. Louis -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

Andrzej Krzemienski

4:09 p.m.

śr., 29 maj 2019 o 18:03 Louis Dionne via Boost napisał(a):

...

Boost - Dev mailing list wrote

...
Dear Boost Community,

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc>; -- targeting C++11 -- to be endorsed for review.

[...]

I endorse the review of out_ptr. I think it's a great idea to get feedback from a Boost review before standardizing a library, and I wish more folks chose to go down that road.

Thanks for doing your due diligence JeanHeyd, and I hope the Boost review can gather useful feedback. Louis

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;

Zach Laine

4:23 p.m.

On Wed, May 29, 2019 at 11:09 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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

JeanHeyd Meneide

10:26 p.m.

On Wed, May 29, 2019 at 12:23 PM Zach Laine via Boost wrote:

...

On Wed, May 29, 2019 at 11:09 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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

JeanHeyd Meneide

2 Jun 2 Jun

2:08 a.m.

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... . 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 wrote:

...

On Wed, May 29, 2019 at 12:23 PM Zach Laine via Boost < boost@lists.boost.org> wrote:

...
On Wed, May 29, 2019 at 11:09 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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

degski

5:45 a.m.

On Sun, 2 Jun 2019 at 05:09, JeanHeyd Meneide via Boost < boost@lists.boost.org> wrote:

...

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

Amusingly, this tends to happen to people that use outdated compilers. Why don't you try VS2019 [and if it then still falls over report a bug/defect]? degski -- @realdegski

JeanHeyd Meneide

7:15 p.m.

On Sun, Jun 2, 2019, 01:45 degski via Boost wrote:

...

On Sun, 2 Jun 2019 at 05:09, JeanHeyd Meneide via Boost < boost@lists.boost.org> wrote:

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

Amusingly, this tends to happen to people that use outdated compilers. Why don't you try VS2019 [and if it then still falls over report a bug/defect]?

degski -- @realdegski

...

pbristow＠hetp.u-net.com

3 Jun 3 Jun

9:04 a.m.

-----Original Message----- From: Boost On Behalf Of JeanHeyd Meneide via Boost Sent: 2 June 2019 20:15 To: boost@lists.boost.org List Cc: JeanHeyd Meneide Subject: Re: [boost] [ boost.out_ptr ] [ Review Endorsement ] New Library targeting C++11 On Sun, Jun 2, 2019, 01:45 degski via Boost wrote:

...

On Sun, 2 Jun 2019 at 05:09, JeanHeyd Meneide via Boost < boost@lists.boost.org> wrote:

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

Amusingly, this tends to happen to people that use outdated compilers. Why don't you try VS2019 [and if it then still falls over report a bug/defect]?

degski -- @realdegski

Dear Degski, It works on VS 2019 and 2017 just fine. I just have to think about what I should do about VS 2015 (if anything at all), since that compiler claims to be a C++11 compiler and this is supposed to be a C++11 Library. Since this is a *new* library, current Boost guidance is that you should not expend much effort on trying to get it to work with earlier than VS 2017. Getting your library to work with current VS, GCC and Clang compilers working IS needed. Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

degski

1:12 p.m.

On Mon, 3 Jun 2019 at 12:04, Paul A Bristow via Boost wrote:

...

It works on VS 2019 and 2017 just fine. I just have to think about what I should do about VS 2015 (if anything at all), since that compiler claims to be a C++11 compiler and this is supposed to be a C++11 Library.

It can claim all it wants, but it's not. Since this is a *new* library, current Boost guidance is that you should not

...

expend much effort on trying to get it to work with earlier than VS 2017.

Exactly my thinking. Getting your library to work with current VS, GCC and Clang compilers

...

working IS needed.

I thought OP said it was working with VS17 and VS19. I presume that means it also works with current Clang's/GCC's. degski -- @realdegski

JeanHeyd Meneide

2:20 p.m.

On Mon, Jun 3, 2019 at 9:13 AM degski via Boost wrote:

...

On Mon, 3 Jun 2019 at 12:04, Paul A Bristow via Boost < boost@lists.boost.org> wrote:

I thought OP said it was working with VS17 and VS19. I presume that means it also works with current Clang's/GCC's.

degski -- @realdegski

Yes! The library works with the Big 3 compilers, and a few others I got my hands on to manually test. I don't have a wealth of testing infrastructure and machines accessible to me, and the travis-ci is rather bare (just testing on the vanilla clang and gcc that come off the shelf from their builds). Sincerely, JeanHeyd Meneide

David Sankel

4 Jun 4 Jun

12:07 p.m.

On Wed, May 29, 2019 at 12:03 PM Louis Dionne via Boost < boost@lists.boost.org> wrote:

...

Boost - Dev mailing list wrote

...
Dear Boost Community,

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc>; -- targeting C++11 -- to be endorsed for review.

[...]

I endorse the review of out_ptr. I think it's a great idea to get feedback from a Boost review before standardizing a library, and I wish more folks chose to go down that road.

Thanks for doing your due diligence JeanHeyd, and I hope the Boost review can gather useful feedback.

+1. I'm also eager to see this in Boost.

Michael Caisse

2 Jun 2 Jun

2:42 a.m.

On 5/26/19 23:00, JeanHeyd Meneide via Boost wrote:

...

Dear Boost Community,

After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc -- targeting C++11 -- to be endorsed for review.

Thank you JeanHeyd for your effort so far with this library. I was in San Diego when outptr was reviewed in LEWG. I believe that completing a Boost review (sooner than later) would benefit the community as a whole. I would participate in an outptr review. michael -- Michael Caisse Ciere Consulting ciere.com

1986

Age (days ago)

1994

Last active (days ago)

List overview

Download

19 comments

11 participants

participants (11)

Andrzej Krzemienski
David Sankel
degski
Gavin Lambert
Gottlob Frege
Hans Dembinski
JeanHeyd Meneide
Louis Dionne
Michael Caisse
pbristow＠hetp.u-net.com
Zach Laine