Boost logo

Geometry :

Subject: [ggl] cartesian distance
From: Barend Gehrels (barend.gehrels)
Date: 2010-05-11 23:08:00


Yesterday I had the presentation at BoostCon about Boost.Geometry.

One of the remarks was about cartesian_distance.

The distance function currently returns a "compatible to numeric" type.
For Cartesian coordinate systems, this is cartesian_distance. For
spherical/geographic coordinate systems, it is just a double (or other
floating point type).
So the return type is a type of the used strategy.

This seemed a good idea. cartesian_distance avoids the square root, so
it is comparable while not taking the expensive sqrt. And if you want
the real distance, it is converted automatically to a double.

However, Eric Niebler noticed that this might give potential problems as
well. If things like meta-programming are done with the return type, it
might raise problems because cartesian_distance is not a numeric type.
It will fit nowhere in the current boost typetraits system, or math
system, or whatsoever. Because cartesian_distance is just a struct.
Adapting it to a fully compatible numerical type seems to me like an

When you compare distances, you normally know that in your code. So it
is not harmful to create a completely separate distance function e.g.
"comparable_distance", which returns a (numerically typed) value, which
is the square (for cartesian). So it works.

There were several other inconveniencies as well with this structure (if
you're interested see comments in the source file "distance_result.hpp")
so I'm actually happy to take it out and using the comparible_distance
function. Which will give other issues as well (such as having 2
strategies, or giving them a policy, to take or not take the sqrt) but I
think it is necessary to do it.

Regards, Barend

Geometry list run by mateusz at