On sexta-feira, 1 de novembro de 2013 15:35:50, Marc Mutz wrote: > According to the standard, they are equivalent, since reading a value from > an enum object that does have one of the declared enum values results in > undefined behaviour. That said, we're violating that in many places in Qt, > e.g. in QFlags, so it might be that the code in question also abuses > m_state that way. in that case, the existing code would be more robust, but > faces the compiler optimising away the & NoErrors due to the reason > mentioned above.
QFlags is not violating anything. First of all, an enum is required to be backed by an integer big enough to hold at least all values of the enum. That means all OR combinations of existing values will fit the enum and will not result in undefined behaviour. I can't think of any place where we might be doing that. It's definitely not in the API, but it might happen in backend code where QFlags was deemed too heavyweight for a simple flags, but in most cases the value is stored directly in an int. And even if that were the case, QFlags does not store an enum. It stores an int, which has a very defined behaviour of storing bitwise OR combinations of known values. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
