Re: [boost] Re: pqs-1-00-00 is up at yahoo

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.