Geometry Boost List: Re: [geometry] Boost.Geometry models initializer_lists (was: Boost.Geometry models UDLs)

Subject: Re: [geometry] Boost.Geometry models initializer_lists (was: Boost.Geometry models UDLs)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-02-26 16:38:41

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

One remark to my own statement above. It's not true. tuple_list_of() 
returns assign_detail::converter< assign_detail::generic_list<...> > 
which can be casted to the arbitrary Container type. This type however 
AFAIU must define a ctor taking a pair of iterators and store elements 
copy constructable from boost::tuple<>.

> 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.
>

Got it.

>>
>> 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 agree, as far as this means "another string run-time solution" :).

Do you think that the support for C++11 initializer_list is needed (and 
sufficient). It would probably look like this:

polygon_type polygon{ {{0, 0},{0, 10},{10, 10},{10, 0},{0, 0}} ,
                       {{1, 1},{2, 1},{2, 2},{1, 2},{1, 1}}};

or that we should also provide a chaining tool working in C++98? Which 
could look like this:

polygon_type polygon = make_geometry<polygon_type>( 
make_geometry<ring_type>(0, 0)(0, 10)(10, 10)(10, 0)(0, 0) )
                                                   ( 
make_geometry<ring_type>(1, 1)(2, 1)(2, 2)(1, 2)(1, 1) );

or

polygon_type polygon = make_geometry<polygon_type>(0, 0)(0, 10)(10, 
10)(10, 0)(0, 0) ,
(1, 1)(2, 1)(2, 2)(1, 2)(1, 1);

Regards,
Adam