Hi Arkadiy, 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 this subject. regards Andy Little