From: Andy Little (andy_at_[hidden])
Date: 2005-12-15 17:27:49
Apologies that I missed this reply before.
"Arkadiy Vertleyb" wrote
> Andy Little wrote:
>> It might be as well to note that this functionality [integral
>> and floating point promotions] is provided by Boost.Typeof,
>> however Boost.Typeof can cause very slow compile times.
> This should not be the case for such simple types as integrals and floating
> points, though. In such case the main overhead doesn't come from type
> encoding/decoding, but rather from the need to pass non-used items through
> the function boundaries, which is a mauch smaller overhead. Also, it should
> be easy to factor out yet another macro where one could provide the size of
> the vector used for encoding (unfortunately, this is a pre-processor
> constant, and can't be figured out by the typeof library based on the actual
> type). If this size is set to one, I don't see _any_ overhead.
> Let me know if this sounds useful.
My approach to typeof is to use it for anything external to my library, whilst
using my own type deduction internally. I expect that other libraries will do
the same thing, so I dont know how easy it would be to try to keep track of the
number of types in the vector. Only the user could do this and IIRC the idea was
to remove as much work for the user as possible. I would for example expect
other library authors to use typeof to facilitate use of the tentative boost (
or non-boost) physical quantities types as value_types.
On this subject there are several libraries which could then allow the tentative
boost physical quantities types as value_types. I think that complex ( ok not
boost exactly) and interval , quaternion, as well as perhaps rational ( for
bigints at least, but also for rational quantities) could potentially be
rewritten this way. I would be interested in the authors or maintainers views on
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk