[boost] Re: typeof

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2004-07-12 08:01:29

David Abrahams wrote:
> 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
> 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.

This is the message I was talking about. And to me it means, that 
__typeof__ is not acceptable because it's not standard. Maybe I don't 
understand the message? The library needs some way to find out the type 
of an expression, __typeof__ works today for some compilers, in the 
future, we might have something like decltype and we can switch to it 
once it becomes available. Even if it's not compatible with __typeof__ 
directly, I'm sure it will provide the functionality needed. The details 
might differ, but I would be more than surprised to find out that 
decltype would not provide what is needed. So doesn't this mean that I 
can't use __typeof__?

Maybe you refer to the fact that the message suggests that all I need is 
an appropriate fallback, but this depends on whether or not such a 
fallback is available. AFAICT, no proposed typeof-emulation was able to 
work for the unit-library examples I've shown, but maybe I haven't tried 
hard enough. But given that nothing worked for me, the conclusion for me 
is, that I can't use typeof because it (or decltype) is not (yet) standard.

>>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?

Hm, sorry, this is my fault. I think I haven't posted an analysis *why* 
all approaches of typeof-emulation won't do for the constant library. I 
just thought about these things, taking into account the examples for 
unit-libraries, and decided it won't work. The reason is, that the 
author of the constant library (or the constants) cannot know which 
unit-libraries are to be supported, and the author of the unit-library 
doesn't want to register stuff for a specific constant library. 
Dependencies. The problem is, that you have to register operators for 
pairs of arguments, one from the unit library, the other from the 
constant-library. Who is supposed to do that? But I also remember that 
this was a problem anyway, as -depending on the design of the 
unit-library- it sometimes worked out-of-the-box, sometimes it didn't. I 
guess I will have to work this out more detailed, but currently, I don't 
have time for it...

>>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.

Oh, I missed the "full language support soon"-part. Again, sorry.

> IMO __typeof__ is an option as long as there's a fallback for
> compilers that don't support it.

As an alternative: Would a limited functionality be OK, too? In my case, 
meaning you can use the constant library with all types that have the 
same result type for operators as their arguments, e.g. T+T gives you a 
T, etc. This doesn't hold for unit-types, where we need typeof instead 
of the simple assumption above, but it still provides lots of useful 
functionality for "normal" types.

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial solutions & technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de