Boost logo

Boost :

From: Dan W. (danw_at_[hidden])
Date: 2003-12-10 09:05:55

Andy Little:
>The quiet message is that there is not a great deal of interest in my
>physical-quantities type. Thats fine with me :-)

I've had a bookmark to your web-pages for a couple of weeks, at the root of
my favorites, --not even in the programming folder; the quiet message is
'there IS interest; no news == GOOD news... ;-) Great write-up. I'm
nobody to make suggestions here, but I just thought that you and Matthias
Schabel could team-up: He appears to be ahead in code, but behind in
docs; you appear to be behind in code but ahead in docs ... ;-)

One thing I worry about on the code side is template name lengths. This
goes for just about anything boosty. Not just a matter of some compilers
being limited to 512 character identifiers, but also from the point of view
of understanding messages in the debugger.
Someone wrote a column for CUJ a number of issues ago, about a technique to
trim template names by deriving a class from a long template name class.

typedef std::pair< std::string, file_handle_t > val_t; //assume
file_handle_t also long template
typedef std::hash_map< std::string, val_t > hm_t; //long name, iterator
name worse

struct file_hm_t : hm_t //this is now a new type, with short name

One problem with this is that constructors have to be provided, which may
be tedious to type if there are multiple argument constructor
overloads. But in many cases, template types in metaprogramming don't even
have constructors other than compiler provided ones. Does this sound
useful? Or is it already used, and I'm just late for the party? ;-)

Back to quantities and units, I'm also curios how will they play together
with the constants project.

And I'm also curious how will it integrate with numerics. One error often
made in numerical programming is the use of floating point types as
accumulators or integrators, unaware of the fact that precision decreases
with the magnitude of the value stored. For angles, a neat solution for an
'angle-accumulator' variable is to use a fixed point 32-bit unsigned
fractional, whose overflow value matches 360 degrees, yielding a
non-degrading resolution of 3.314 milli-arc-seconds. A 64-bit unsigned
fractional can be used for more precise astronomical integrations. The
advantage of mapping the numeric representation's natural overflow to 360
degrees is that it implements a 'circular number' without the added cost of
boundary checks or mod operations... less code, better performance.

Just throwing that in, as an example of how platform configuration ties
with numerics, which again tie with units and with constants. It would be
nice to see all these separate projects eventually merge and offer a
comprehensive solution addressing the whole field of value semantics.

Just my $0.015.

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