Boost logo

Geometry :

Subject: Re: [geometry] Is "dimensions" signed or unsigned?
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-09-21 18:59:02


Hi Patrick,

2014-09-21 21:45 GMT+02:00 Patrick J. LoPresti <lopresti_at_[hidden]>:

> While compiling boost::geometry with a very old compiler (GCC
> 4.1.2-redhat ; please do not ask why), I got a slew of warnings about
> signed-vs-unsigned integer comparisons.
>
> These warnings are harmless, of course, and I can disable them. But it
> occurs to me that perhaps it would be better if boost::geometry were
> consistent.
>
> For example, in core/coordinate_dimension.hpp, assert_dimension() and
> similar functions treat "Dimensions" as an int; while in
> index/detail/algorithms/is_valid.hpp, "Dimensions" is a size_t.
>
>
Yes, this reminds me that this warning is also produced by newer versions,
e.g. 4.4. I'm not sure when GCC stopped doing so. Unfortunately when unit
tests pass, warnings aren't displayed on the regression summary page so we
can't see all of the warnings on all platforms. Not to mention that not all
platforms are tested.

> It looks to me like most of the library uses size_t for the dimension,
> which makes sense to me. Are the developers amenable to patches
> silencing these warnings by using size_t consistently? (Or int; I
> personally do not mind either choice, as long as it is consistent.)
>
>
I fixed signed/unsigned comparison in index/.../is_valid in develop branch.

The problem with dimension<> metafunction is that the type of the value
depends on the traits defined for a Geometry. For all models in
Boost.Geometry int type is used but the user may define it as unsigned or
size_t, etc. So I'm guessing that we can't be fully consistent here.
However we can take care about signed/unsigned comparison warnings.

Of course if you think that something could be improved, not only this
issue, patches are more than welcome.
In case you didn't know, here is a tutorial:
https://github.com/boostorg/geometry/wiki/Contribution-Tutorial
The above is true not only in the case of the code but also the
documentation or GitHub wiki.

Regards,
Adam



Geometry list run by mateusz at loskot.net