Geometry Boost List: Re: [geometry] Using Boost.Geometry with a legacy class hierarchy

Subject: Re: [geometry] Using Boost.Geometry with a legacy class hierarchy
From: Mats Taraldsvik (mats.taraldsvik_at_[hidden])
Date: 2012-02-20 03:03:39

Hi Barend,

On 02/19/2012 11:05 PM, Barend Gehrels wrote:
> Hi Mats,
>
> Herewith another and better solution on your question
>
>
> On 19-2-2012 22:41, Barend Gehrels wrote:
>> Hi Mats,
>>
>> On 17-2-2012 12:10, Mats Taraldsvik wrote:
>>> Hi,
>>>
>>> With the help of boost::iterator_facade and stackoverflow.com [1], 
>>> I've almost managed to adapt the Ring concept to my legacy objects, 
>>> but I got a compile time error which I don't understand. As you can 
>>> see from the code, the iterator exposes QPoint* objects directly, so 
>>> that should work properly.
>>>
>>> The cpp files and the errors from the build log is here [2].
>>>
>>> [1] 
>>> http://stackoverflow.com/questions/9251537/how-to-create-a-boost-range-that-hides-multiple-layers-of-vectors-and-exposes-it
>>> [2] https://gist.github.com/1852693
>>>
>>> Regards,
>>> Mats Taraldsvik
>>>
>
> If you achieve to not use the pointer-versions but just the normal 
> versions, everything becomes a lot easier. You can then still use the 
> pointer-versions in your ring. But you add the QPoint version to the 
> traits.
>
> This is not that difficult.
>
> The iterator implementation then needs only a small difference:
>
>         R dereference() const {return 
> *(*lineStringIter_)->points[pointIndex_];}
> (we deference it here)
>
> and the typedefs:
>     typedef RingIteratorImpl<std::vector<QLineString*>::iterator, 
> QPoint> RingIterator;
>     typedef 
> RingIteratorImpl<std::vector<QLineString*>::const_iterator, const QPoint>
>             ConstRingIterator;
>
>
> So we basically consider it as iterating over QPoint& and not over QPoint*
>
> I did not check the iterator_base there might be other (better) 
> solutions for this as well, but this basically works at least.
>
> Having done this, the wkt streaming works (without any change to 
> Boost.Geometry). And besides this you can expect a lot less problems 
> because you handle a point as a point and not as a pointer.
>
> If you do the same for linestring you can remove the pointer version 
> to the traits (did not do that).
>
> My adaptions are here:
> http://codepad.org/4a3TxTGN
>
> So this does not need any change to Boost.Geometry.
>

Thanks for your help :)

The object hierarcy is a bit more complex than my current example (also 
contains 2d, 3d points, curves etc.), and objects are stored in pointer 
to base/super-containers. Therefore, I can't remove the pointer 
requirement, I'm afraid. I guess creating separate pointer and 
non-pointer specializations (e.g. point_type and point_type_ptr) since 
they are so different, means either a lot of duplicated code, or a very 
difficult problem...

I was also hoping to overcome the pointer-to-base container issue also, 
but thought it was best to take one step at a time. :)

> Regards, Barend
>

Regards,
Mats

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