From: David Abrahams (dave_at_[hidden])
Date: 2004-07-12 09:42:12
Daniel Frey <daniel.frey_at_[hidden]> writes:
> 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.
I'm don't see why you'd need to register operators. If I'm not
mistaken, with Arkadiy's solution you only need to register
user-defined types and templates (and maybe functions if they are used
as template arguments).
> 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.
It seems reasonable that a library acquires added features on
compilers where language extensions are available.
> 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.
Seems OK to me, in principle.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk