Boost logo

Geometry :

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



Geometry list run by mateusz at loskot.net