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.

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