Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2006-08-29 16:48:59

"Jeff Garland" <jeff_at_[hidden]> wrote in message
> Ben Strasser wrote:
>> Jeff Garland <jeff <at>> writes:
>>>> typedef unit<length, "m"> meter;
>>> This isn't valid code...can't give char strings to templates.
>> I was talking about an ideal world. ;)
> Ok, well we don't have that world...
>>> The problem is hardcoding the "m" anywhere -- this shouldn't be done. You
>>> need an I/O facet that has the defaults and can be overridden by the user at
>>> runtime. This allows different output for the same value in the same
>>> process.
>>> Your view of how to solve this is on the wrong course in my view...
>> I depends on the situation. Some units are unique to the application. Here we
>> probably wont need any internationalization so hard coding "m" will do the
>> job
>> just fine.
> Boost is an international organization with an international audience so it's
> a different context to do something only for yourself.
>> There are however also other units. For example length units. It might be
>> useful
>> to let the programmer use meters in his program and have it output feet based
>> on
>> the local in the stream.
>> What I mean is something like:
>> cout.imbue(new unit_out_facet<length, feet>("", "ft"));
>> wcout.imbue(new unit_wout_facet<length, feet>(L"", L"ft"));
>> //or
>> cout.imbue(new unit_out_facet<length, meter>("", "m"));
>> wcout.imbue(new unit_wout_facet<length, meter>(L"", L"m"));
>> //...
>> cout<<meter(4); // will print meter or feet based on the current local
>> This seems as a good idea to me and this is possbile to implement.
> On the right track, but this scares me a bit. I'm not sure I want conversions
> in the facet code. I think I'd rather the user do that explicitly.
>> Input would be a bit more tricky.
> Input is much harder...because you only have access to an input iterator. You
> can't backtrack. So suppose you want to handle input like this:
> 10 m
> 10 meters
> 10 microseconds
> The first 2 are a valid length -- the last isn't. Anyway, it's sticky.

FWIW I think that the problems of I/O of quantities( at least in SI Units ) are
orthogonal to the main bulk of a quantities library. IOW its probably not that
difficult to work on this type of functionality independent ( as far as
possible) of a particular library.

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at