Boost logo

Boost :

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-13 00:22:46


Matthias Schabel wrote:
>>> Not necessarily. static_multiply has to be
>>> able to operate on an mpl::list.
>> I don't know where you come up with that requirement. It certainly
>> makes sense to me that if you have a library that is as intimately
>> tied
>> with MPL as this one is that you use the standards created by the MPL.
>
> As Steven pointed out, this is not a detail - how would you write a
> template
> specialization of mpl::times<> that works for an arbitrary mpl::list?
> By defining
> my own compile time operators, I can default to mpl lists and
> specialize where
> necessary.

SHRUG - I don't know. When I find I have to alter standards because of
a path of implementation I chose I look at my choice and see if there
might be an alternative. Granted, MPL isn't exactly a standard but it
does try to set a few. A dimension type that works with mpl::times<>
doesn't seem like that outrageous a thing to do when compared to
implementing a new type of wheel and all that entails.

>> quantity<SI::length> cent(cents);
>> cent = 2 * meters;
>> assert(cent.value() == 200);
>
> I have no idea what this means. Cents == centimeters? If so,
> centimeter is not an SI unit of length. And with no
> value, the first line doesn't give you a quantity anyway...

Yes, I know...your library can't do this. That's my point so your
saying so doesn't exactly do much to counter. I think it pretty obvious
what it 'means'. 2 meters get assigned to a value in
centimeters...should come out with the value 200...you're syntax would
have to be expanded.

...

> I'm sorry to say that I can't make heads or tails out of what you
> want here.

It's a moot point. No, it isn't possible within your framework...at
least not easy. But as you're set in your way and not really open to
this anyway...and since I'm in the minority it seems...it's going to be
what it's going to be. I'm not going to struggle against the wind on
this one.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk