Geometry Boost List: Re: [geometry] Adapting a model

Subject: Re: [geometry] Adapting a model
From: TONGARI J (tongari95_at_[hidden])
Date: 2014-03-25 23:09:44

2014-03-26 5:29 GMT+08:00 Barend Gehrels <barend_at_[hidden]>:

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