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

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