On Thu, Jun 27, 2019 at 12:23 AM Gavin Lambert wrote:
On 27/06/2019 09:46, Louis Dionne wrote:
I find the customization point appropriate. I find that a lot of people's adversity for specialization and opening namespaces is not founded. My experience so far has been that ADL-based customization points, on the contrary, have more pitfalls and are harder to use. So I like the proposed design for customization points.
Perhaps I'm missing something, but as I read it the proposed design for customization is "specialize out_ptr itself".
Which could alternatively be written as "reimplement the entire library yourself".
So I'm not sure I agree that this could be called a "customization point"...
Right. ADL was just one suggestion of many by Andrey. Another suggestion was trait specialization. Nobody is against specialization, or opening namespaces. ADL can be avoided too. But there is value in not having to re-implement out_ptr_t by a full specialization of it. At that point the author of LibX doesn't care about LibZ::out_ptr and LibZ::out_ptr_t at all: they would just be implementing LibX::out_ptr and LibX::detail::out_ptr_t.
There's one thing I really dislike about the implementation, though. It's the clever aliasing trick. While it is clever, it's unsafe and it adds complexity to the library. In my opinion, this kind of thing should live merely in a separate experimental branch, or always be enabled in the cases where we know for sure it's safe (I think that's never but I'm not sure).
I tend to agree. While strict-aliasing rules are a bit of a pain in the butt, sneaking around behind them and poking private members of unique_ptr and friends doesn't seem like a good idea, even if it does improve benchmarks.
It's not a good idea. I believe the author when he says that there are users who refuse to use the version without UB because they need the performance; he has that data. But that doesn't justify the UB in Boost.
And "UB-based optimization" does not inspire confidence.
Glen