Hi Eric.

On 26/05/2015 02:43 μμ, Eric MSP Veith wrote:
Hello Menelaos,

On Friday 22 May 2015 17:33:35, Menelaos Karavelas 
<menelaos.karavelas@gmail.com> wrote:
My OGRPointCollectionIterator is both default and copy constructible:
I think the question is whether your mutable iterator is convertible to
your const iterator, or to pose it differently, whether your const
iterator is constructible from your mutable iterator (which should be
the case).
I'm still puzzled. I've checked my iterator code and updated some of it in 
order to have it adhere to the Boost iterator_facade howto as closeley as 
possible. Specifically, I made sure that `MyConstIterator iter = 
boost::begin(someNonConstLineString);` works, which would cause the iterator 
to be converted to the const iterator.

So I assume that it is not the iterator that is at fault.

Checking your example and investigating the Boost.Geometry headers, I see that 
the bg::model::linestring<...> trait relies on several functions via 
dispatching that are present in std::vector and other container types, but not 
in OGRLineString. This includes, as seen from the compiler error I posted 
previously, clear(), push_back(), and resize().

I'd now open up the boost::geometry::traits namespace and provide dispatch 
structures for these operations along the lines of...


template <>
struct clear<OGRLineString>
{
    static inline void apply(
            typename rvalue_type<OGRLineString>::type range)
    {
        range.empty();
    }
};


Would that be the correct approach or merely a hack?

Yes, this IS the correct way. You need to specialize various metafunctions in bg::traits namespace so that things work.
Please keep us posted about this.

- m.



Thanks
Eric


_______________________________________________
Geometry mailing list
Geometry@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/geometry