[geos-devel] GeometryCollection constructor

strk strk at keybit.net
Wed Oct 8 10:27:48 EDT 2003


nhv wrote:
> strk writes:
> > nhv wrote:
> > > strk writes:
> > > > 
> > > > but my question is: should memory copy go further copying each
> > > > object in the vector instead of just the vector itself ?
> > > 
> > > Ack...
> > > 
> > > I thought we were going to use reference counted pointers
> > > just so we could *safely* pass pointers instead of objects around
> > > and not have to worry about objects being prematurely deleted
> > > or conversely needlessly left on the heap !!
> > 
> > Sometimes you really want a copy, because you are going to modify it,
> > while sometimes a pointer would be just fine ... 
> 
> Indeed we need 'deep' and 'shallow' copy methods
> 
> > You might make a copy when needed, but it would be better to make
> > it *MANDATORY* for developers willing to modify returned objects
> > (would a 'const'  work for that?). 
> 
> this should work by passing a 'const pointer' when that is what is wanted

what if I pass a 'const pointer' to a vector of pointers to
private/protected/read_only Geometries ? would that be a 
const pointer to vector<const Geometry *> ?
And again, will CoordinateList internal to each geometry be
modifiable by geometry's public method or they would get 'const'ed 
as well ?

> 
> > Alternatively every change to an object
> > should be done using public methods that in turn should check ownership
> > of the object (caller object address? is that available?) and transparently
> > make a copy of it when needed ... 
> 
> Or just use the 'deep' copy method when appropriate.
> But we certainlly don't want to be copying every data structure every operation
> or GEOS will return to a 'crawl' as it was with it's initial 'naive' Java Translation

Ok, I understand this. So we should talk about a specific change:
CoordinateList *Geometry::getCoordinates()
When the geometry is a Point, there is no CoordinateList element,
so it is created on-purpose.
When the geometry is a Polygon a CoordinateList object must be
created in order to contain all CoordinateLists of all rings.
When the geometry is a LineString an available internal CoordinateList
exists and was returned.

Now, I made LineString always return a copy, as all other types do
( as suggested by xie ). I might have used auto_ptr for other cases
of creation instead, is that what you are saying ? In that case
callers would not bother deleting method result value. But then again
sometimes the CoordinateList returned by calls to this function is
reduced by means of its own method removeRepeatedPoints which did
delete internal vector and created a new one. This was unacceptable,
because at the end an internal CoordinateList *
(LineString::points - protected) would have been modified (deleted?)
by a function that had nothing to do with LineString itself.

Would declaring
const CoordinateList *LineString::getCoordinates()
have solved this ?

--strk;



More information about the geos-devel mailing list