From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2019-06-28 08:48:55
Dear David Sankel,
Thank you for the review.
I fixed up the documentation in the places you requested. (It's on the
post-review branch.)
I did not use Boost.Test for the reason Zach pointed out: testing
infrastructure (and CI, and etc.) was to be ported upon a successful
review. The current set up is for ease of use and benchmarking / test
deployment outside of the typical boost infrastructure (to allow
contributions and reviews to be done easier): it will be replaced with the
Boost-based infrastructure later.
I turned off the cleverness in both out_ptr and inout_ptr by default.
It now takes defines to turn on the aliasing optimization (documented in
the post-review branch, here:
https://github.com/ThePhD/out_ptr/blob/feature/boost.review/docs/out_ptr/config.adoc#configuring-boostoutptr).
This answers both your and many other's concerns about the aliasing, as
well as some of Peter Dimov's specific concerns about how the aliasing is
done.
I do not believe inout_ptr to be an abstraction so bereft of value: it
has already seen successful use and is an important wrapper for many
delete-and-allocate/reallocating C APIs, and one of my first users used it
for their code.
I do not have a design for a new customization point: this is the one
I settled on after extensive research into various different areas. I do
not think I should change it: but the need for simplicity is important. I
could offer a facade to make it easier to implement the boilerplate and
avoid concerning a user with storage directly, but struct specialization is
still the most flexible and can cover more use cases effectively.
Sincerely,
JeanHeyd Meneide