Subject: Re: [geometry] dimension type of geometries
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-07-24 21:41:44
2013/7/23 Barend Gehrels <barend_at_[hidden]>
> 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).
Does OGC allow negative dimensions? If not, should we assume that they
won't be used in the future?
> 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.
This would probably correspond to numeric_limits<size_t>::max().
> What is your actual proposal? Making core_traits::dimension of size_t? Can
> you send a patch before?
I was thinking about defining traits::dimension for point, point_xy and
c-array to be consistent with Boost.Geometry template perameters. I thought
about it because when signed dimension is compared with some unsigned
value, e.g. in static_assert, some compilers complain about it.
So we could:
- leave it as it is now
- define size_t in traits only for BG types and allow ints for other types
- define size_t in traits for all types (also for Fusion and Tuple) but
allow ints for user-defined types
- force size_t in core_traits
I'm not proposing anything particular and won't insist on some specific
solution. What do you think about it?
Geometry list run by mateusz at loskot.net