Re: [boost] Preview 2 of a template Geometry Library

From: Barend Gehrels (barend_at_[hidden])
Date: 2008-03-26 09:34:20

> The Original poster's submission (not sure if it is a review) falls
> dismally short of what a generic templates computational library
> should be at the bare minimum let alone something useful by the
> general populace.
Quite a statement. I limit my answer to this: the submission is a 
preview, as mentioned in my posting.

> One other thing I forgot to mention, was when looking at the provided
> link http://geometrylibrary.geodan.nl/points.html
>
> The distance definition takes 2 templated point types but always
> returns a double. The lesson here is that the precision required for
> the the result may be more than the precision of the inputs. In this
> case the best strategy is to at the minimum return the same numeric
> type of the points as the result type or better.
>   
The distance of two integers may result in a floating point value. 
Therefore distance returns a double. Internally, you will see, often, 
the same numeric types or better is used as you describe. See 
select_type_traits and large_type_traits.
> The other issue is that the points should be of the same type, not
> differing types. This strategy_traits approach where assuming there
> will be an implementation for the combination of types is not
> adequate, what if one of the types can be easily promoted to the
> other?
>   
Points of different types can be handled.
If you use a derived class, you have to provide an appropriate traits 
class. It is not promoted. At least not in the compilers I use.
Besides that, the library user might choose to specify a strategy.
> eg: double conversion to my_super_duper_arbitrary_precision_floating_point_type
> via copy constructor? does that mean I have to provide a wrapper around the
> explicit call to my implementation of distance with my specific type?
Indeed the distance result could use a large_type_traits as well.

Barend Gehrels