soasis / out_ptr Goto Github PK

https://github.com/ThePhD/out_ptr/blob/b4e7cf3e20cf0e5936f2611e83131984e2eabeef/include/boost/out_ptr/detail/base_out_ptr_impl.hpp#L78 is the move constructor and calls Base(std::move(*this)).

AFAIK this is UB because this (including the Base part of this) is not initialized, so it does access uninitialized memory -> UB

Just like in the title, for the whole abstraction! No more regular asserts, only Boost ones! You will be using the boost.assert library and replacing any std::abort / assert calls you see with descriptive BOOST_ASSERT_MSG calls.

Some internal work needs to be done for boost::shared_ptr. Specifically, an additional OR'd condition needs to be added to this place here to ensure that boost::shared_ptr does not fall into the same pitfall as std::shared_ptr as documented by that static_assert.

The goal will be to forward declare the boost::shared_ptr type and then write the another is_specialization_of call there.

An example should be written using boost::intrusive_ptr with the Microsoft COM API. You can adapt the example as shown in this documentation here.

This example should just demonstrate how to use std::out_ptr with boost::intrusive_ptr: it can be filled in here.

This example should apply #ifdef _WIN32 ... #endif around it, since getting it to compile will require including Windows SDK types and classes.

An example should be written using a std::shared_ptr and boost::shared_ptr with a C API. There is a fictional C API with ficapi: you can look at the tests here to see it and see the actual shim repository and its functions.

This example should just demonstrate how to use std::out_ptr and std::inout_ptr with std::shared_ptr and boost::shared_ptr: it can be filled in here and here.

An example should be written using the pthread API (example here) that shows the usage of out_ptr to retrieve the exit value returned by the executed pthread function. It should show off the out_ptr<void*>(...).

The example can be written into here. Since this is Linux-specific, it should be gated by a #ifdef __linux__ ... #endif.

This is meant to be a C++11 Boost Library. Therefore, all C++14-isms must go away. One of those C++14-isms if std::enable_if_t: it should be replaced by boost::mp11::mp_if_c<(Boolean Condition), void>!

This issue is to make sure none of those are left.

If I read the implementation correctly, the clever_out_ptr can double-free the smart pointer.

Setup:

• Have a unique_ptr with a value (non-NULL)
• Pass this into a function via clever_out_ptr
• function fails and does not set the pointer
• clever_out_ptr checks the original pointer, sees it is != null and calls the deleter
• deleter of unique_ptr calls delete on the same ptr

Am I missing anything or can you confirm this bug?

An example should be written using a std::unique_ptr with a C API. There is a fictional C API with ficapi: you can look at the tests here to see it and see the actual shim repository and its functions here.

This example should just demonstrate how to use std::out_ptr and std::inout_ptr with std::unique_ptr: it can be filled in here.

This library needs documentation.

While it is a simpler library, having all of the important information in the proposal is not suitable for submission to Boost. We need a form of documentation and a way of documenting it.

Some documentation systems we could use:

• ascii doc
• Sphinx

We also need a quick overview in the readme.

A more involved customization point should be written for boost:;move::unique_ptr, following the clever_out_ptr_impl optimization and the clever_inout_ptr_impl optimizations applied to std::unique_ptr. The type should be forward-declared and then hooked into the same optimization.

One area that more tests could be performed for is to test if resource leakage occurs if an exception is thrown after the desired API is used and there's a failure. There is a function in the tests for producing a "failure": please use it and test what happens if an exception is thrown and caught post-success and post-failure.

There's a couple typos in the documentation that my eyes glanced over despite several read throughs.

Lovely.

New libraries should use boost::library:: namespaces. e.g. boost::out_pointer:: (or boost::out_ptr::, but boost::out_ptr::out_ptr doesn't look very nice).

i.e. Only the older existing libraries use just namespace boost::. All newer libraries have been required to create a namespace within boost:: and use that.

Your detail namespace then becomes boost::library::detail::.

Transitioning namespaces but having any compiler failure result in success made me blind: I missed it was checking the wrong error.

Probably in a config.adoc

We need contiguous integration. There are a number of providers. The two I am most familiar with are:

• Appveyor, for Windows builds
• TravisCI, for Linux builds

There are other providers but I do not know how to use them.

The core of this should be setting up the platform and then invoking the following:

• cd the_build_dir (optional)
• cmake path/to/source/dir -GNinja -DCMAKE_BUILD_TYPE=Debug -DBOOST_OUT_PTR_TESTS=ON -DBOOST_OUT_PTR_EXAMPLES=ON -DBOOST_OUT_PTR_CI=ON
• ctest --build-config Debug --output-on-failure

A C++17-ism is the type traits that are suffixed by _v. What it does is produce an actual boolean value representing the original type trait's ::value boolean: either true or false. All instances of _v need to be removed to explicitly used the regular type trait and then getting it suffixed by ::value.