Boost logo

Geometry :

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

Geometry list run by mateusz at