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".)