[geos-devel] SegmentString modeling

strk at refractions.net strk at refractions.net
Fri Feb 17 03:39:23 EST 2006

On Thu, Feb 16, 2006 at 07:12:32PM +0100, Mateusz Å?oskot wrote:
> strk at refractions.net wrote:
> >Are you suggesting SegmentString should take ownership
> >of the passed CoordinateSequence ?
> >This is not how it currently works. Not that I like current
> >behaviour, but I'm trying to understand your suggestion.
> >
> >In the examples you show B takes ownership of B*, things
> >get simpler in that case. But when B does not own C, changing
> >C isn't the same as changing B.
> In my example B owns object assigned to B::c because it's simple example 
> and my aim was to make it correct.
> But in my idea ownership of object assigned to B::c is not important.
> We are talking about const correctness what does not depend on objects 
> ownership.

I somehow disagree on this.
If B does not own C*, changing C* should not be the
same as changing B iself.

> How is responsible to destroy CoordinateSequence assigned to 
> SegmentString in current solution?
> As I see SegmentString's destructor does not do it.
> So, if you will make SegmentString::pts member as non-const:
> CoordinateSequence *pts;
> it won't change the situation regarding ptr ownership at all.

No, but it won't be able to assign a const pointer to it.

The problem can be seen in operation/Buffer/OffsetCurveSetBuilder.cpp.
The addCurve(const CoordinateSequence* coord) function constructs
a SegmentString passing it 'coord'. This is possible as far as
SegmentString promises not to change 'coord' itself.
Indeed SegmentString won't change it, but then it won't provide
any method to get a non-const ref to let others change it.
This (changing CoordinateSequence trhough SegmentString) would
be required by the ScaledNoder class, which I'm about to port
from JTS.

Currently, the CoordinateSequence ownership is:
	- of OffsetCurveBuilder (ptList)
	- of SegmentNodeList 
	- of Edge (in EdgeNodingValidator, unused actually)

I guess making SegmentString own the CoordinateSequence could
be a viable solution for now.


More information about the geos-devel mailing list