David Abrahams wrote:
I'm not convinced that this particular ODR violation ends up being a problem in practice, though -- ultimately we end up getting the same type out of any typeof(...), and if we're never generating linker symbols within the computation performed by typeof, we're probably going to get away with it. I think it's worth trying an automatic scheme and stress-testing it to see if we can make it break. Better yet, explicitly construct a pared-down version _designed_ to break and see if we can cause a problem.
Just to understand you correctly: When I used typeof() in my constant library, I was told that it is not acceptable because it's not yet standard. Although both the EDG-based compiler I used (Intel) and the GCC offered __typeof__. Now people are trying to emulate the functionality of typeof. They want users to register their types and the library is still not as capable as a native typeof. Try the examples I provided for unit-library-compatible constants. And now you even say that it's OK to violate existing language rules on purpose just because you think it will likely work in practice? Sorry I don't get this. If violating the existing standard is an option, than __typeof__ should be an option as well. My 2¢. Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de