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

Subject: Re: [geometry] Boost.Geometry models initializer_lists
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-02-26 16:46:25

Hi Adam,

Adam Wulkiewicz wrote On 26-2-2014 22:38:
> 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) );
>
>

This looks very good, I like this very much. The C++11 too (but I don't 
yet use that).

Though I like it very much I still doubt if there is wide need for it...
But maybe indeed in some of our own unit tests.

>
> 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);

With comma operator, hmm, don't know yet. I think we get into problems 
with multi-polygons (having inner rings too) then? That comma-operator 
also has nasty side effects w.r.t. preference IIRC (e.g. use it in a 
ternary-operator...).

Regards, Barend