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
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
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
The boost_facade documentation is very good, though, so I hope to make
it work. :)
> Thanks, Barend
> Geometry mailing list
Geometry list run by mateusz at loskot.net