4 ms·
It does, however, work fine if you use a proper "* (Badge<T>* )&stub" cast.
by a1369209993 7y ago
It does, however, work fine if you use a proper "* (Badge<T>* )&stub" cast.
- GrayShade 7y agoIsn't casting unrelated types undefined behavior?
- brianush1 7y agoYes, in the standard it isn't defined, but on most--or maybe even all?--systems and compilers it's perfectly defined, since there is no reason why a compiler would layout two different empty structs in different ways; they're both empty anyways. Edit: Actually, from reading some of the other comments in the thread, the standard apparently specifies that empty structs are 1 byte in size, so technically they would both be the same size, so casting between them should be fine.
- kazinator 7y agoIt's not defined on systems unless a document spells it out. However, the actual behavior can be deduced to be harmless from black-box testing. compiler source code and generate object code.
- kazinator 7y agoProblem is that it doesn't require a diagnostic, and the actual behavior of casting one empty struct foo {} to another empty struct bar {} is likely harmless and portable.
- kazinator 7y agoWell, that's a problem in the C++ type system, isn't it; because it (effectively) constructs a value of type Badge<Device>, even though it's not a piece of code sitting in the Device class scope. The rule should be that if the default constructor of T is not accessible in the scope, then any cast to T * or T & requires a diagnostic. Or something like that. If I can allocate a suitably aligned buffer of sizeof (T) zeros, and then treat that as a T, I've effectively constructed a T.
- a1369209993 7y agoNo, that's a good feature of the C++ type system, because it (effectively) allows the programmer to construct a value of type Badge<Device>, even if Device thinks it's okay to prevent that. It would be better to do eg "return Device::private:get_badge()", but C++ defectively doesn't support that.