Hi Barend,

2015-01-24 12:00 GMT+01:00 Barend Gehrels <barend@xs4all.nl>:

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