Boost.Geometry models UDLs

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Boost.Geometry models UDLs

Adam Wulkiewicz
Hi,

I was wondering if it would be possible to implement some nice UDL for BG models. I thought it would be great to have a compile-time WKT which whould work e.g. like this:

"LINESTRING(0 0, 1 1, 2 2)"_wkt

if we could parse this in compile-time we'd be able to return proper type. Unfortunately AFAIK it's (currently?) impossible to parse string literals in compile-time. If you could proof me wrong I'd be very glad :). So I've implemented some simplified version which can be found here:

https://github.com/awulkiew/test_boost_geometry_udl

Any ideas are welcome. It works like this:
using namespace bg::literals::cart2d;

"(1 1)"_pt; // point<double, 2, cs::cartesian>
"(0 0, 2 2)"_box; // box<p2d>
"(0 0, 1 1, 2 1)"_ls; // linestring<p2d>

// polygon<p2d> - for now the default cw closed, should probably be ccw
"((1 0, 1 3, 3 3, 3 0, 1 0))"_poly

// ring<p2d> - for now the default cw closed, should probably be ccw
// also non-WKT definition could be used - without doubled parentheses
"((1 0, 1 3, 3 3, 3 0, 1 0))"_ring
Of course you must compile it with some compiler supporting user-defined literals, e.g. GCC >= 4.7 or Clang >= 3.1

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

Mateusz Loskot
Administrator
On 30 January 2014 14:32, Adam Wulkiewicz <[hidden email]> wrote:
>
> I was wondering if it would be possible to implement some nice UDL for BG
> models. I thought it would be great to have a compile-time WKT which whould
> work e.g. like this:
>
> "LINESTRING(0 0, 1 1, 2 2)"_wkt

IMHO, great idea.
Sorry, can't dig it deeper now.

Best regards,
--
Mateusz  Łoskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

Barend
In reply to this post by Adam Wulkiewicz
Hi Adam,


Adam Wulkiewicz wrote On 30-1-2014 15:32:
Hi,

I was wondering if it would be possible to implement some nice UDL for BG models. I thought it would be great to have a compile-time WKT which whould work e.g. like this:

"LINESTRING(0 0, 1 1, 2 2)"_wkt

if we could parse this in compile-time we'd be able to return proper type. Unfortunately AFAIK it's (currently?) impossible to parse string literals in compile-time. If you could proof me wrong I'd be very glad :). So I've implemented some simplified version which can be found here:

https://github.com/awulkiew/test_boost_geometry_udl

Any ideas are welcome. It works like this:
using namespace bg::literals::cart2d;

"(1 1)"_pt; // point<double, 2, cs::cartesian>
"(0 0, 2 2)"_box; // box<p2d>
"(0 0, 1 1, 2 1)"_ls; // linestring<p2d>

// polygon<p2d> - for now the default cw closed, should probably be ccw
"((1 0, 1 3, 3 3, 3 0, 1 0))"_poly

// ring<p2d> - for now the default cw closed, should probably be ccw
// also non-WKT definition could be used - without doubled parentheses
"((1 0, 1 3, 3 3, 3 0, 1 0))"_ring
Of course you must compile it with some compiler supporting user-defined literals, e.g. GCC >= 4.7 or Clang >= 3.1

Interesting.

Note that I did some experiments in the past to get a similar effect, though implemented differently. If we would use Proto we are able to compile things like this:

    // Initialize a ring:
    typedef bg::model::ring<bg::model::d2::point_xy<double> > ring_type;
    ring_type ring = geometry_of(16, 1)(15,2)(14, 3)(13,4)(12, 3.14)(1,6);
    std::cout << bg::wkt(ring) << std::endl;

It does obviously not have the WKT syntax, but it should be possible to parse any geometry type with this.

See ....\extensions\example\experimental\geometry_of.cpp
(it is unfinished)

Regards, Barend



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

Adam Wulkiewicz
Hi,

2014-01-30 Barend Gehrels <[hidden email]>:

Adam Wulkiewicz wrote On 30-1-2014 15:32:
I was wondering if it would be possible to implement some nice UDL for BG models. I thought it would be great to have a compile-time WKT which whould work e.g. like this:

"LINESTRING(0 0, 1 1, 2 2)"_wkt

if we could parse this in compile-time we'd be able to return proper type. Unfortunately AFAIK it's (currently?) impossible to parse string literals in compile-time. If you could proof me wrong I'd be very glad :). So I've implemented some simplified version which can be found here:

https://github.com/awulkiew/test_boost_geometry_udl

Any ideas are welcome. It works like this:
using namespace bg::literals::cart2d;

"(1 1)"_pt; // point<double, 2, cs::cartesian>
"(0 0, 2 2)"_box; // box<p2d>
"(0 0, 1 1, 2 1)"_ls; // linestring<p2d>

// polygon<p2d> - for now the default cw closed, should probably be ccw
"((1 0, 1 3, 3 3, 3 0, 1 0))"_poly

// ring<p2d> - for now the default cw closed, should probably be ccw
// also non-WKT definition could be used - without doubled parentheses
"((1 0, 1 3, 3 3, 3 0, 1 0))"_ring
Of course you must compile it with some compiler supporting user-defined literals, e.g. GCC >= 4.7 or Clang >= 3.1

Interesting.

Note that I did some experiments in the past to get a similar effect, though implemented differently. If we would use Proto we are able to compile things like this:

    // Initialize a ring:
    typedef bg::model::ring<bg::model::d2::point_xy<double> > ring_type;
    ring_type ring = geometry_of(16, 1)(15,2)(14, 3)(13,4)(12, 3.14)(1,6);
    std::cout << bg::wkt(ring) << std::endl;

It does obviously not have the WKT syntax, but it should be possible to parse any geometry type with this.

See ....\extensions\example\experimental\geometry_of.cpp
(it is unfinished)


Ok, thanks. This expression is quite simple, I think it could be easily implemented without Proto. Wouldn't including Proto significantly increase the compilation time? I fear that nobody would use it. But now with C++11 something similar could be easily achieved with unified initialization and initializer lists:

ring_type ring{{16,1},{15,2},{14,3},{13,4},{12,3.14},{1,6}};

// not entirely sure but maybe something 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}}};

and btw we should probably support it anyway.

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

Bruno Lalande
Hi,

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.

Regarding C++11 I guess it's a more general question of which direction Boost generally want to take...

Regards
Bruno

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

Barend
Hi Bruno,


Bruno Lalande wrote On 24-2-2014 10:46:
Hi,

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

Regards, Barend


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

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

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

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

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.


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


Regards, Barend


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models initializer_lists (was: Boost.Geometry models UDLs)

Adam Wulkiewicz
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

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models initializer_lists

Barend
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 mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

Andrew Hundt
In reply to this post by Adam Wulkiewicz

I proposed to support UDLs because this is the feature from the C++ and we should be up-to-date :).

I would be wary of jumping to support new features just because they are there unless the new solution is undeniably better than existing backward compatible techniques. :-)

In my opinion there isn't such a gap so initializer lists make more sense to me.

Cheers!
Andrew Hundt
 

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models initializer_lists

Adam Wulkiewicz
In reply to this post by Barend
Hi,

Barend Gehrels wrote:

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.


Ok, so I propose to add only the support for the initializer_list.



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

Yes, you're right. I didn't thought about MultiPolygon.

Regards,
Adam


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models UDLs

Adam Wulkiewicz
In reply to this post by Andrew Hundt
Hi,

Andrew Hundt wrote:

I proposed to support UDLs because this is the feature from the C++ and we should be up-to-date :).

I would be wary of jumping to support new features just because they are there unless the new solution is undeniably better than existing backward compatible techniques. :-)

If it was possible to parse them in compile-time then it would be better ;)

In my opinion there isn't such a gap so initializer lists make more sense to me.


I agree.

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models initializer_lists (was: Boost.Geometry models UDLs)

Bruno Lalande
In reply to this post by Adam Wulkiewicz
Hi,

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?

Do we really have the choice? Aren't Boost libraries supposed to always support pure C++98?

Bruno

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models initializer_lists

Adam Wulkiewicz
Hi,

Bruno Lalande wrote:
Hi,

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?

Do we really have the choice? Aren't Boost libraries supposed to always support pure C++98?


I doubt it. Around Boost various features are used  when they're supported by the compiler. Often they're of course emulated in C++98 but even then this has limitations so effectively there are things which can be done only in C++11. What is more, some people on the list already mentioned about the implementation of libraries which would require some features from C++11 to compile.

We could just check:

#ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Geometry models initializer_lists

Bruno Lalande
Hi,

I doubt it. Around Boost various features are used  when they're supported by the compiler. Often they're of course emulated in C++98 but even then this has limitations so effectively there are things which can be done only in C++11. What is more, some people on the list already mentioned about the implementation of libraries which would require some features from C++11 to compile.

Oh OK I didn't know that - great then, makes sense to bring that feature if C++11 is available. There's actually a lot of things that could be better done with C++11 features.

Regards
Bruno

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Adapting a model

Veekay
Hello,

I 'm looking to adapt a model for use with Boost.Geometry. To start off,
I looked to get the intersects algorithm working with two linestrings -
that fails due to six MPL assertions (unimplemented operation).(note
that my model's linestring cannot be mutable - it should still be
possible to use non-mutating algorithms on it?)

To try to track what's going on, I opted to get it working with the
example model adaptation instead; that fails to compile too, on line 934
of get_turn_info.hpp:

typename strategy::return_type result = strategy::apply(p1, q1);

And I am afraid I cannot tell what is missing.

(In short, I copied the example QPoint and QLineString adaptation and
added a main() calling intersects() - this is what I tried to compile:

https://gist.github.com/Kojirion/9624531

Just one minor correction - changed QPoint::double to double because I
assume that's the intention)

Any clues would be appreciated,

Albert
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Adapting a model

Adam Wulkiewicz
Hi,

Please don't answer on some email from a different thread if you want to
create another thread.

-- Original message --

Hello,

I 'm looking to adapt a model for use with Boost.Geometry. To start off,
I looked to get the intersects algorithm working with two linestrings -
that fails due to six MPL assertions (unimplemented operation).(note
that my model's linestring cannot be mutable - it should still be
possible to use non-mutating algorithms on it?)

To try to track what's going on, I opted to get it working with the
example model adaptation instead; that fails to compile too, on line 934
of get_turn_info.hpp:

typename strategy::return_type result = strategy::apply(p1, q1);

And I am afraid I cannot tell what is missing.

(In short, I copied the example QPoint and QLineString adaptation and
added a main() calling intersects() - this is what I tried to compile:

https://gist.github.com/Kojirion/9624531

Just one minor correction - changed QPoint::double to double because I
assume that's the intention)

Any clues would be appreciated,

Albert

-- End --

According to this:
http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/reference/concepts/concept_linestring.html
the Linestring should behave like a range of Points.

I don't know what was the intention that led to the example model
adaptation but if you replace pointers to QPoint in your example with
just a QPoint it compiles, almost.
Almost, because apparently the Point's default ctor is required by Box's
default ctor.

Barend is default ctor a part of the Point Concept? Or should we think
about some other way of default creation of Boxes/Segments/etc.?

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Adapting a model

Barend
Hi,


Adam Wulkiewicz wrote On 25-3-2014 3:42:

> Hi,
>
> Please don't answer on some email from a different thread if you want
> to create another thread.
>
> -- Original message --
>
> Hello,
>
> I 'm looking to adapt a model for use with Boost.Geometry. To start off,
> I looked to get the intersects algorithm working with two linestrings -
> that fails due to six MPL assertions (unimplemented operation).(note
> that my model's linestring cannot be mutable - it should still be
> possible to use non-mutating algorithms on it?)
>
> To try to track what's going on, I opted to get it working with the
> example model adaptation instead; that fails to compile too, on line 934
> of get_turn_info.hpp:
>
> typename strategy::return_type result = strategy::apply(p1, q1);
>
> And I am afraid I cannot tell what is missing.
>
> (In short, I copied the example QPoint and QLineString adaptation and
> added a main() calling intersects() - this is what I tried to compile:
>
> https://gist.github.com/Kojirion/9624531
>
> Just one minor correction - changed QPoint::double to double because I
> assume that's the intention)
>
> Any clues would be appreciated,
>
> Albert
>
> -- End --
>
> According to this:
> http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/reference/concepts/concept_linestring.html 
>
> the Linestring should behave like a range of Points.
>
> I don't know what was the intention that led to the example model
> adaptation but if you replace pointers to QPoint in your example with
> just a QPoint it compiles, almost.
> Almost, because apparently the Point's default ctor is required by
> Box's default ctor.
>
> Barend is default ctor a part of the Point Concept? Or should we think
> about some other way of default creation of Boxes/Segments/etc.?

No, a point does not need to have a default constructor. It is not part
of the concept. There is already a sort-of-constructing function in the
library and that is boost::geometry::make, returning a point with
specified coordinates.

For Box/Segments we don't have this yet, so yes, we should think about that.

However, QPoint has a default constructor, so in code of library users
it is fine if that constructor is used. As long as it does not leak into
our library.

Regards, Barend



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Adapting a model

TONGARI
2014-03-26 5:29 GMT+08:00 Barend Gehrels <[hidden email]>:
Hi,


Adam Wulkiewicz wrote On 25-3-2014 3:42:

Hi,

Please don't answer on some email from a different thread if you want to create another thread.

-- Original message --

Hello,

I 'm looking to adapt a model for use with Boost.Geometry. To start off,
I looked to get the intersects algorithm working with two linestrings -
that fails due to six MPL assertions (unimplemented operation).(note
that my model's linestring cannot be mutable - it should still be
possible to use non-mutating algorithms on it?)

To try to track what's going on, I opted to get it working with the
example model adaptation instead; that fails to compile too, on line 934
of get_turn_info.hpp:

typename strategy::return_type result = strategy::apply(p1, q1);

And I am afraid I cannot tell what is missing.

(In short, I copied the example QPoint and QLineString adaptation and
added a main() calling intersects() - this is what I tried to compile:

https://gist.github.com/Kojirion/9624531

Just one minor correction - changed QPoint::double to double because I
assume that's the intention)

Any clues would be appreciated,

Albert

-- End --

According to this:
http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/reference/concepts/concept_linestring.html
the Linestring should behave like a range of Points.

I don't know what was the intention that led to the example model adaptation but if you replace pointers to QPoint in your example with just a QPoint it compiles, almost.
Almost, because apparently the Point's default ctor is required by Box's default ctor.

Barend is default ctor a part of the Point Concept? Or should we think about some other way of default creation of Boxes/Segments/etc.?

No, a point does not need to have a default constructor. It is not part of the concept. There is already a sort-of-constructing function in the library and that is boost::geometry::make, returning a point with specified coordinates.

Doesn't geometry::make require the geometry default constructible?
AFAIK, there's no such trait for point construction.

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
12