[geos-devel] GeometryCollection constructor

[strk]

If giving direct access to private data is ok for everybody,
I will change getCoordinates() behaviour back to its pre-patch one,
adding a 'const' keyword to function definition and using auto_ptr
when creating custom new CoordinateLists. 

Then, we'll have to discuss about constructors arguments: shall
those be freely deleted by caller or instead taken under
constructed object responsability ?


--strk;

nhv wrote:
> strk writes:
> > 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 !!
> > 
> > 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.
> 
> I suggest that if one *must* copy data then one derive new classes
> from the low-level geos classes that IMHO should *never* copy data
> for performance reasons. < well hardly ever >.  This way there can 
> be a 'safe' interface for those that don't feel comfortable with the
> responsibilities that come with having the 'raw' acess that is necessary 
> for *speed*.  
> 
> Cheers
> 
> Norman
> 
> 
>  
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel