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