Boost logo

Boost :

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);

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at