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

Subject: Re: [geometry] Boost.Geometry models UDLs
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-02-26 15:59:27

Adam Wulkiewicz wrote On 26-2-2014 19:37:
> 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.

No, I did not mean to exactly, literally, use tuple_list_of . I meant: a 
solution "using chaing operators", like tuple_list_of. So just like your 
examples below.

>
> 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 don't think there is much need of. I just reacted on your message, 
because I don't think there is a need to have another string solution.

>
>
> 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, Barend