https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #21 from mark <markrubn at yahoo dot com> --- (In reply to Jonathan Wakely from comment #19) > The main reason is that reinterpret_cast subverts the type system. > Constant expressions have to be free of undefined behaviour, which is > impossible to do if arbitrary nonsense^W code that violates the type > system is supported. Sorry, I still don't understand. Yes, reinterpret_cast subverts the type system. In this case that's intentional, as there's no other way (that I know) to have an arbitrary class pointer to an arbitrary memory address. (I've tried placement new without success.) The behavior here is non-portable, but well defined. If it wasn't, the runtime reinterpret_cast would also be undefined. Why are/should constant expressions be different? (In reply to Jonathan Wakely from comment #20) > And doesn't exactly the same thing work fine in C++? I don't understand the point. Yes, a C++ compiler will accept the C code. But it will still be C, without the object-oriented advantages of C++ (the C code has external functions taking struct pointers instead of instance methods, etc, etc.) As I illustrated, it's impossible to have a C++ class with an unsigned* const member pointing to an arbitrary memory address -- and still have the object constexpr constructed/initialized in .data -- as it is in C. BTW, I am very committed to strong type-safe system design. See my FOSS repositories at https://github.com/thanks4opensource/regbits and https://github.com/thanks4opensource/regbits_stm for examples. It is precisely the inability to constexpr construct a class containing an Object* const pointer (or, alternately, a reference) to an instantiation of the class templates in those systems that led to this request -- the unsigned* examples I used here were for minimal/clear illustration. As always, I appreciate the feedback, and would welcome any solution within the current standard that satisfied all the requirements I've laid out. I have researched the topic online without finding anything other than the workaround I described.
