Re: [Boost-users] [units][geometry] subtract_typeof_helper<> help!

Subject: Re: [Boost-users] [units][geometry] subtract_typeof_helper<> help!
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-01-03 01:28:09

>> Construction works here for me, but calculating distance does not.
>> Because distance behind the screens takes the square root, after
>> squaring. This requires thorough integration with Boost.Units at
>> those places, which is not planned.
> 
> I understand that integrations with Boost.Units is not planned and
> even not desirable.
> But making the implicit assumption that
> typeof(sqrt(s)) == typeof(s) or that typeof(s*s)==type(s)
> makes it incompatible with Boost.units. Those assumptions are good as
> defaults but there should be a way to tell Boost.Geometry that
> sometimes it is not the case.

I took a stab at a generic solution to this problem of units and data types in a geometry library with Polygon.  My coordinate_traits defines a distance time, area type etc.  I then look up what data type to use for the return value of a distance or area calculation.  Because it is a point of customization the user can specify data types with assoicated Boost.Units.  My main concern was overflow at the time, but I think having a point of customization (meta function that can be specialized) and using it consistently would allow a generic geometry library to interoperate with Boost.Units without needing to be integrated with Boost.Units.  Generic programing should allow exactly these types of compatibility between libraries without directly coupling them.  Is there any reason why this approach wouldn't work? 

Thanks,
Luke