[boost] Re: Re: new compile-time dimensional analysis and unitlibrary

From: Andy Little (andy_at_[hidden])
Date: 2003-12-12 23:22:17

"Phil Richards" <news_at_[hidden]> wrote in message
news:20031212120219.A9FAB8C0D3_at_derisoft.derived-software.demon.co.uk...

[ response to Mattias Schnabel]

> In answer to your favourite question:

[solution to Mattias Schnabels problem]

Thanks for answering Mattias Schnabels problem ... the solution looks
clean.I especially like this...  nice way to do things when pointed out
of
course:

>typedef plus<mass, acceleration>::type force;

On the raw performance thing. It is surely only one factor in making a
successful type. I'd  tend to put that later on the agenda, ...the "early
optimisation" thing
. The part that has been ignored, and which I keep banging on about is the
user interface.( e.g. Yes...Compile Times,useful error messages(Concept
checking works well) and the "look and feel" of the type. Unless the type
does one simple thing clearly consistently and well, is simple to use
without requiring to write a function template every time you wish to
calculate e.g in my current syntax( q_force::N * q_length::m) and has decent
documentation...it will join the rest in the graveyard.

It needs: simplicity  , simple syntax, consistent semantics, documentation
thereof, consideration of the user (e.g fast compile, no odd habits, ),and
...good performance.

std::string;    OK underneath its a template.. As a user I dont want to know
about how its implemented. I dont want to modify the defaults if I
can help it... I just want to use it... Which is what I am trying to achieve
with my version of this type.

Yes I would be interested in another view. I would suggest using the boost
sandbox rather than the files section? (The files section will sooner or
later run out of space) Create a directory ("physical" as good a name as
any?) and put all the various versions in one place. Seems to be an approach
that has worked well on Math constants.

regards
Andy Little