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
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:
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk