From: Andy Little (andy_at_[hidden])
Date: 2006-09-09 18:54:36
"Andy Little" <andy_at_[hidden]> wrote in message
> "Joel de Guzman" <joel_at_[hidden]> wrote in message
>> Andy Little wrote:
>>> BTW. By using a tuple rather than an array, then you can use representing
>>> and one. IOW zero<T> one<T> .
>>> template <typename TL, typename TR>
>>> zero<typeof(TL() * TR() )>
>>> operator *( Tl , zero<TR>)
>>> return zero<typeof(TL() * TR() )>();
>>> It should be relatively simple for the compiler to optimise such calcs away.
>>> Very useful for matrix calcs.
>>> (originally suggested by Geoffrey Irving).
>> Indeed. Also, with Fusion, you have the option to use purely
>> constant sequences such as mpl::vector_c together with plain
>> sequences, or even user defined sequences and adapted/converted
> Right. I started looking into this scheme for math ops. I opted for a zero and
> one, but then I figured that one + one should go to two etc.
> In the end I opted for a static_value<StaticValue,RunTimeType>
> StaticValue could then be any of mpl::int_ etc, though for mpl int_ division
> ( can be) lossy so at that point the division should turn the result into the
> RunTimeType. other possibilities for StaticValue are a compile time rational,
> maybe with a long long value_type. At any point where the compile time value
> will run out of steam then the type will be automatically converted to the
> All in all... how to take a simple idea and make it very very complicated :-)
Oh Yeah, and plug in variadic templates, auto, and stick the kettle on while
waiting for it to compile and you will probably not spend as much time worrying
about sparse matrices. ;-)
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk