Geometry Boost List: Re: [geometry] Support of C++11 initializer list

Subject: Re: [geometry] Support of C++11 initializer list
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2015-01-24 07:24:33

Hi Barend,

2015-01-24 12:00 GMT+01:00 Barend Gehrels <barend_at_[hidden]>:

> Hi Adam,
>
>
> Adam Wulkiewicz schreef op 24-1-2015 om 3:36:
>
>> Hi,
>>
>> Some time ago I added an experimental support for C++ initializer lists
>> in geometries to make possible the creation of geometries using uniform
>> initialization, e.g.:
>>
>> linestring ls = {{0, 0},{1, 1},{2, 2}};
>> polygon poly = {{{0, 0},{0, 5},{5, 5},{5, 0},{0, 0}},{{1, 1},{4, 1},{4,
>> 4},{1, 4},{1, 1}}};
>>
>
>
> Thanks for this, it looks very good.
>
> To draw attention to this (to the list): the polygon contains an interior
> ring, nice.
>
> Do multi-linestrings and multi-polygons (having interior rings too) also
> work and how does it look?
>
>
Yes, there must be yet another list there:
// two linestrings forming a linear ring
multilinestring mls = { {{0, 0},{1, 0},{1, 1}}, {{1, 1},{0, 1},{0, 0}} };

// first polygon containing a hole, the second only the exterior ring
multipolygon mpoly = { {{{0, 0},{0, 5},{5, 5},{5, 0},{0, 0}},{{1, 1},{4,
1},{4, 4},{1, 4},{1, 1}}}, {{{5, 5},{5, 9},{9, 9},{9, 5},{5, 5}}} };

> Does a point work and how does it look? I recently changed the constructor
> there to get rid of a warning we had for a long time about out of boundary
> values.
>
>
Yes, this is why there was the explicit keyword conditionally removed. Now
it's only in the 1-argument ctor that's marked as explicit. I'm not sure if
it's possible to use 1d points in the initializer list, probably not, so we
may think about removing the keyword also for the 1-argument ctor. This
would mean that a 1d Point may be treated as a number. This could be useful
if someone e.g. wanted to use the 1d R-tree as an interval tree, to search
for intervals or closest value.

>
>
>> The goal was to support C++11 initializer lists and Boost.Assign in the
>> same time even if Boost.Assign currently doesn't work on all compilers with
>> STL containers. FYI, there is a PR with proposed fix but nobody is willing
>> to merge it.
>>
>
> Hmm... I see no messages on the boost ML, maybe that would help too?
>
>
>> Anyway, to work around it and avoid ambiguity while using Boost.Assign to
>> assign new data to the geometry I implemented only the constructor taking
>> std::initializer_list. This way the compiler prefers the conversion from
>> Boost.Assign generic_list directly into the Geometry because conversion
>> first to std::initializer_list would require 1 more conversion.
>>
>> It seems that everything is ok on all compilers except the msvc14 CTP, I
>> hope they'll fix it in the final release. See http://www.boost.org/
>> development/tests/develop/developer/geometry.html, the test geometries.
>>
>> So if you'd like to try it out you have to checkout the develop branch
>> and define BOOST_GEOMETRY_EXPERIMENTAL_ENABLE_INITIALIZER_LIST. Please
>> let me know if it works for you.
>>
>> The final question is, should we enable it by default in Boost 1.58?
>>
>
> That depends on the consequences for MSVC 14. If they don't fix it, and
> that results in our geometries being unusable, we should not do it. If just
> that feature is unusable, it looks OK to me. What is the case?
>
>
It's Boost.Assign which is unusable. It's also unusable with std::vector<>
on this compiler.

> If so, we should add a doc-page with examples too.
>

Of course.

Regards,
Adam