[geos-devel] SegmentString modeling

[Mateusz Łoskot]

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.

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.

If you are asking about ownership in my example (my idea) you have two 
choices simple:

1 - SegmentString owns CoordinateSequence passed by pointer to 
SegmentString constructor. So, CoordinateSequence owned by SegmentString 
is destroyed in SegmentString destructor.

2. - CoordinateSequence is not owned by SegmentString but then it must 
be *explained* in the documentation and user (client of SegmentString) 
is required to deallocate CoordinateSequence passed to SegmentString.
In this situation SegmentString acts as a handler of CoordinateSequence.
Similar "solution" is used in GDAL where you have static factory methods 
like CreateFeature and deallocators like DestroyFeature.


Another idea is to provide a kind of garbage collector to this hierarchy 
  in form of smart pointers e.g. shared_ptr from Boost library.
Note: there are many types of smart pointers so it should be analyzed 
which one fits most here.

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net