Geometry Boost List: Re: [geometry] Boost.Geometry models UDLs

Subject: Re: [geometry] Boost.Geometry models UDLs
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-02-26 13:37:11

Hi,

Barend Gehrels wrote:
> Bruno Lalande wrote On 24-2-2014 10:46:
>> Sorry for the late reaction. Good idea indeed. Not sure we need 
>> Proto, given the limited number of operators will be using (just one 
>> AFAICT). We should try without first. Also, Proto is a very complex 
>> library and trying to manually do its job first is usually a good way 
>> to understand it. 
>
> Sure - I mentioned Proto just to spread the knowlegde of similar 
> experimental UDL that I had done. Not really to advocate the usage, I 
> agree it is complex.
>
> But besides that I think using chaining operators is a little more 
> convenient, think of boost::tuple_list_of of Boost.Assign which is IMO 
> more convenient to use than compile-time strings, and looks better.
>
> |"((1 0, 1 3, 3 3, 3 0, 1 0))"_ring
> vs.
> |ring_type ring = tuple_list_of(16, 1)(15,2)(14, 3)(13,4)(12,3.14)(1,6);
> Such things are easy to create (also without proto).

tuple_list_of() returns a vector of boost::tuples: 
http://www.boost.org/doc/libs/1_55_0/libs/assign/doc/index.html#tuple_list_of
so in order to work the above ring_type should define a ctor to which 
this list could be passed.

It could also look like that:

ring_type ring = make_geometry<ring_type>(16, 1)(15,2)(14, 
3)(13,4)(12,3.14)(1,6);

or:

ring_type ring;
fill_geometry(ring)(16, 1)(15,2)(14, 3)(13,4)(12,3.14)(1,6);

which requires only the Ring concept.

However I'm not sure if such functionality is needed in general. There 
are rare situations when someone must define some complex geometry in 
the code. Probably only in some (unit-)test, so mainly for us. Or maybe 
I'm wrong?
If someone needed this kind of tool he'd need 10 lines of code for this.

I proposed to support UDLs because this is the feature from the C++ and 
we should be up-to-date :).
For the same reason I proposed to support initializer_lists  when available.

Initially I thought that it would be possible to parse the string in 
compile-time and generate proper type but this is not possible.

FYI, Metaparse was mentioned on the Boost list as a solution for this.
http://abel.web.elte.hu/mpllibs/metaparse/manual.html#the-input-of-the-parsers
http://abel.web.elte.hu/mpllibs/metaparse/MPLLIBS_STRING.html
https://github.com/sabel83/metaparse_tutorial#metaparse-tutorial

As a result, there would be some macro, e.g. BOOST_GEOMETRY_WKT breaking 
the string into chars and passing them as template parameters to the 
compile-time template-based parser.

auto polygon = BOOST_GEOMETRY_WKT("POLYGON((30 10,40 40,20 40,10 20,30 
10))");
auto point = BOOST_GEOMETRY_WKT("POINT((0 0))");
// etc.

But I don't like this solution.

Hence I proposed just to support initializer_lists.

Regards,
Adam