Geometry Boost List: Re: [geometry] dimension type of geometries

Subject: Re: [geometry] dimension type of geometries
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-07-23 17:52:35

Hi Adam,

On 17-7-2013 16:03, Adam Wulkiewicz wrote:
> Bruno Lalande wrote:
>> Hi Adam,
>>
>> Seems to make more sense indeed, you can either make the change (and run
>> the whole BG testing suite) or submit this as a ticket.
>>
>
> Ok, dimension<> for the following types should be changed: point, 
> point_xy, boost::array, c_array, boost::tuple and Boost.Fusion sequence.
> Boost.Tuple and define its length as int, the same is true in case of 
> Boost.Fusion sequence size, but this shouldn't cause any problems. 
> I've added static asserts (0 <= length_or_size) but it's probably not 
> needed.
>
> But this concerns me, two other libraries define values related to the 
> size as ints. Should we take a different approach? Is there a problem 
> with size_t as static constant on some compilers?
>
> In MinGW (GCC 4.7.2) all test are passed.
> In VC there are some errors:
> - related to sqrt() ambiguity which I've described in some other email,
> - in SimplifyStrategy, function pointer is passed to function taking 
> reference.

These were problems of the distance-strategies and are fixed now. Thanks 
for the hint about function pointer, apparently this is not accepted by 
MSVC (clang/gcc do). I changed it into pass-by-value, also in 
DistanceStrategy. About sqrt see previous mail.

>
> Should I commit it?

Good question but  - did you mean the size_t or the bugfixes? The 
bugfixes would have been OK but it is already done now...

About size_t, I don't see the need to change behaviour w.r.t. other 
libraries if it was consistent between them before. Also OGC (our 
reference) defines Dimension as integer (probably because they have a 
general interface and do not have size_t).

Basically it makes sense of course, we have many template parameters 
w.r.t dimension already defined as size_t ...

Unless we want to give -1 (or so) a special meaning (e.g. variable 
dimension) but this is (as far as I remember) never discussed before.

What is your actual proposal? Making core_traits::dimension of size_t? 
Can you send a patch before?

Thanks, Barend