2014-03-26 5:29 GMT+08:00 Barend Gehrels <barend@xs4all.nl>:

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


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

-- Original message --


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:


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

Any clues would be appreciated,


-- End --

According to this:
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.