Daniel Frey <daniel.frey@aixigo.de> writes:
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__.
Perhaps you could post links to specific messages so we can see exactly what was said? If you're talking about http://lists.boost.org/MailArchives/boost/msg59186.php, "it's not acceptable because it's not standard" is not an accurate paraphrase of the message there.
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.
Perhaps you could post links to specific messages?
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?
As an experiment, to see how portable it actually is... and only because we expect to see full language support soon.
Sorry I don't get this. If violating the existing standard is an option, than __typeof__ should be an option as well. My 2ยข.
IMO __typeof__ is an option as long as there's a fallback for compilers that don't support it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com