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-24 07:19:14

Hi Barend,

On 02/22/2012 07:28 PM, Barend Gehrels wrote:
> Hi Mats,
>
> On 22-2-2012 12:53, Mats Taraldsvik wrote:
>> Ok, so even though I define the four "versions" of QPoint (QPoint 
>> const*const, QPoint* const, QPoint const* and QPoint*), 
>> Boost.Geometry can't properly handle/distinguish between the QPoint* 
>> and QPoint const*?
>
> First: you don't have to provide traits for "const" versions, so 
> ending with const. So the QPoint const* const is redundant.
>
> Second, you indeed *have* to provide traits for "const *" version 
> because that is a different type.
>

Ok, got it. Thanks :)

> Boost.Geometry is using boost::remove_const to get the correct traits. 
> But boost::remove_const<QPoint const*> does not remove the const 
> (which is correct).

Correct in the sense of behaviour, though -- not intention (which would 
be to remove the const in QPoint const*), right?

> boost::remove_const<QPoint const* const> correctly removes the last 
> const and keeps the first.
>
> Maybe we can change our library by using something more sophisticated 
> such as
>
> if (is_pointer) add_pointer(remove_const(remove_pointer))
>
> which should remove the need of the const specialization.
>
> We have to discuss that. The const version basically adds something 
> nice too because it defines only the "get" in the traits, and not the 
> "set".

Well, that's a useful feature to have in any case -- one might have to 
deal with objects (references or pointers) that are not mutable. I hope 
this is solvable without losing such a nice feature. :)

If it weren't legacy objects, I'd change them to use the new smart 
pointers (unique_ptr, shared_ptr), which, if I'm not mistaken, should 
behave correctly in Boost.Geometry right now.

>>
>> I guess the only or best available workaround is to iterate through 
>> the QPoint*, and return references to QPoint?
>
> I think so.
> Though (I add this again) I also got it (wkt streaming) working by 
> modifying one line in Boost.Geometry, based on the pointer-version (my 
> first answer).
>

Yes. However, I really don't like to apply custom patches, making 
upgrades to future versions difficult, especially for Boost.Geometry, 
which is moving quickly forward. :)

>> I hope you can solve this. :) If you want to use the code as an 
>> example of adapting legacy classes/objects in the documentation, I'll 
>> be happy to write a few accompanying paragraphs. :)
>
> That is welcome!

I need to adapt the QPolygon as well, and then I'll try to contribute 
the whole adaption example to the documentation. This, adapting the 
QPolygon, is a bit more difficult since it actually requires a random 
access iterator (or, I get a lot of compiler errors relating to this, so 
I'm guessing that's the problem), while my custom RingIterator is a 
forward iterator.

The boost_facade documentation is very good, though, so I hope to make 
it work. :)

>
> Thanks, Barend
>

Mats

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