Geometry Boost List: [geometry] Unexpected behaviour of algorithms with integer coordinate type (possible overflow)

From: Vitaly Davydov (vitprof_at_[hidden])
Date: 2021-07-01 15:58:10

Dear Sirs,

I very like the idea behind BGL but I experience some unexpected behaviour
using the library. I'm using area and intersection algorithms with a custom
point type of int32 coordinate type. I've found that these algorithms
produce wrong results for medium and large coordinate values (probably due
to integer overflow).

For the area algorithm I tried to specify ResultType as double but it
didn't help because internal calculations are executed in the coordinate
type (like get<1> - get<0>) where overflow occurs. My last solution is to
specify the double coordinate type in the traits and perform some rounding
in the set function. Thus, all the calculations will be performed using the
double type.

I have some questions related to the design of the bgl.
1. Is it intended to produce calculations using the coordinate type or are
there some ways to specify the type for calculations? Thus, to distinguish
storage types and calculation types?
2. I think the only coordinate type is not enough. At least there should be
some other type like length (which can be unsigned). How is it matched with
the current design of BGL?
3. Is my solution to specify double type as the coordinate type in the
traits correct? Maybe some other better solutions exist?

Thank you in advance,
Vitaly
<geometry_at_[hidden]>