Boost logo

Boost :

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-03-13 13:03:35


Barend Gehrels wrote:
> So we will let
> them define the way in which they want comparisons to be made (strict
> or tolerant) via the geometry traits already in place. The Point
> Concept
> will have a traits class e.g. "comparison". This will be an enhanced
> version of the "equals" function used now. However, library users can
> implement another comparison class, and attach this via traits to
> their
> point type. Which will be used by floating point equality evaluation.
> This way we handle the defaults correctly, we enable matching of
> points
> which are more distant and still to be considered as equal, and enable
> configurable floating point (comparison) models. If other things then
> equality will be checked, those cases would be handled in the same
> way.
>
> So, in summary, it will be part of the concept, configurable. How FP
> equality then implemented is to be defined, it would be useful if it
> is somewhere within Boost because its scope is broader then geometry
> alone.
>
Doesn't it make more sense to make this a trait of the coordinate concept than adding it onto a specific geometry concept? You could then use the trait of the coordinate for all coordinate comparisions. I would expect there are cases where you need to compare two x values and don't care about the y and it would be awkward to construct points to use the traits of the point for this.

Luke


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk