[geos-devel] SegmentString modeling
mateusz at loskot.net
Thu Feb 16 13:12:32 EST 2006
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
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:
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
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.
More information about the geos-devel