On 07/12/17 13:18, Groke, Paul via Boost wrote:
BTW: someone recently proposed adding - among others - BOOST_MAY_ALIAS. Do you know if there has been any progress there?
Last I remember it was proposed as part of this PR: https://github.com/boostorg/config/pull/82 That PR was not accepted, but mostly due to many unrelated changes, some of which were more controversial than others. I don't remember any more recent attempts, but may be I missed some. 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.
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. Second, the barrier prevents code reordering, possibly CSE and maybe other kinds of optimization even if the code is unrelated to the guarded pointer. Third, I'm not totally sure that the barrier would be effective in all cases anyway. If aliasing_barrier is implemented through atomic_signal_fence then the compiler may still assume that some private data like temporaries and values on the stack cannot be affected by a signal handler and reorder some code across the barrier. 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.