Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-12 06:45:00

Daniel Frey <daniel.frey_at_[hidden]> 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, "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

Boost list run by bdawes at, gregod at, cpdaniel at, john at