Re: [boost] [beast] Formal review

Subject: Re: [boost] [beast] Formal review
From: Groke, Paul (paul.groke_at_[hidden])
Date: 2017-07-12 12:22:28

> From: Andrey Semashev via Boost
> Sent: Mittwoch, 12. Juli 2017 13:22
> 
> I agree that such a macro would be useful in Boost.Config as I know this
> attribute is used in multiple places in Boost. I'll prepare a PR.

Cool, thanks :)

> > I still think that some "nicer" way of doing this would be cool. And the more
> I think about it, the more I'm liking the "aliasing_barrier()" idea. Hmm...
> 
> I don't think this approach is the way to go. First, because it would be
> complicated to use. You would have to guard _every_ context where the
> aliasing pointer is dereferenced with a pair of barriers, and in some contexts
> it is difficult to do (think operator -> or passing the pointed value as a
> function argument). Besides, it's just too easy to miss a place where the
> barrier is needed.

Hm. Maybe you're right. Have to think about this some more.

> I think the attribute is the closest we can get. We could also provide a helper
> like this:
> 
>    template< typename T >
>    T BOOST_MAY_ALIAS* alias(T*);
> 
> Although the caller still needs to know the type T BOOST_MAY_ALIAS*
> (unless he can use auto for that), so I'm not sure how useful that would be.

It could also be used like this:

T* ptr...
for (...) {
    T value = *alias(ptr);
    ptr++;
}

Another possibility would be something like

template <class T>
T aliasing_read(void* address) {...}
template <class T>
void aliasing_write(void* address, prevent_deduction<T>::type value) {...}

Which is what we use in our code.
(I had to try very hard to resist the urge to simply call those "peek" and "poke".)