From: Andrey Semashev via Boost Sent: Mittwoch, 12. Juli 2017 11:07
That would be a problem, yes. Although the use case when a UTF-8 string is represented with an array of ints seems unlikely to me.
Not sure if that makes sense with regard to Beast, but in general ... the UTF-8 string could have been produced by a something-to-UTF-8 encoder. Which might also use some kind of fast path utilizing a "pack" type for writing the UTF-8 bits.
I think the best solution would be to mark size_t with __attribute__((__may_alias__)) and use it instead of plain size_t.
#if defined(__GNUC__) #define BEAST_MAY_ALIAS __attribute__((__may_alias__)) #else #define BEAST_MAY_ALIAS #endif
typedef std::size_t BEAST_MAY_ALIAS pack_t; const pack_t* p = reinterpret_cast< const pack_t* >(string);
Given the tools currently available in std/Boost, I agree. (BTW: someone recently proposed adding - among others - BOOST_MAY_ALIAS. Do you know if there has been any progress there?). 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...