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.