[geos-devel] GeometryFactory argument in Geometry constructors

[Ferdinando Villa]

strk,

what you describe below is so naturally solved with shared pointers that
I suggest to keep copying until I or someone else can integrate that in
geos. I definitely suggest not to mess with flags and stuff. Meanwhile,
a look at www.boost.org could start whetting your appetite for automatic
memory management... we can copy only the relevant files from boost with
(relatively) little effort. I've done it before.

ferdinando

On Thu, 2004-07-01 at 10:48, strk wrote:
> I've found this change does not always work.
> Sometime client application does not have control over Geometries'
> factory. Namely the PrecisionReducer class creates a new GeometryFactory
> for the new Geometry. If Geometry do not take ownership of the factory 
> this results in a memory leak.
> 
> Having Geometry own a private GeometryFactory means you have
> less memory management problems but memory occupation and CPU
> cycles will increase. Take a collection of 100 Geometries.
> This will have 101 GeometryFactories, 101 copies and 101 deletes.
> Each GeometryFactory copy will also copy its PrecisionModel.
> 
> Apart from the fact that this duplication of info might be useless
> (is a collection of Geometries with different Factory valid ?)
> Do we really need it ?
> 
> A possible solution is to specify wheter or not to take ownership of
> passed GeometryFactory. This specification would set a flag which 
> would be checked at Geometry destruction time. Taking ownership of
> a GeometryFactory could mean just destroy it at Geometry destruction
> time, without making any copy at construction time (duplicating 
> a GeometryFactory should be pretty easy). With this setup code
> willing to use a Geometry factory for constructing another Geometry
> should check ownership of it, as the new Geometry might refer to
> a factory which will be destructed by former Geometry destructor...
> 
> Another solution might be reference counting, which I discouraged
> in the past (mainly due to my lack of experience).
> Actually reference counting might more closely reflect JTS, which
> gets memory management for free... This - again - would be a bigger
> change and will shift release time.
> 
> Final and easier solution is to keep copying Factory and forget about
> it.
> 
> Comments ?
> 
> --strk;
> 
> On Wed, Jun 30, 2004 at 10:58:29PM +0200, strk wrote:
> > I ask and answer myself :)
> > I've removed GeometryConstrauctor automatic copy from
> > Geometry constructors. This want change the way applications
> > will call them.
> > 
> > Now on with the ref/pointer switch for ownership...
> > 
> > --strk;
> > 
> > On Wed, Jun 30, 2004 at 09:49:14PM +0200, strk wrote:
> > > Another element which should be take part of the next API
> > > is GeoemtryFactory. GEOS-1.0 did not have geom constructors
> > > taking GeometryFactory (did have PrecisionModel and SRID which
> > > the constructors used to build a new Factory). Next GEOS will
> > > have GeometryFactory as an argument to the constructor (so to
> > > have PrecisionModel and SRID already defined there).
> > > 
> > > Would the factory element of each Geometry be better a pointer
> > > to external resource or a owned copy ? It is currently a copy
> > > so I was wondering. If we need both behaviour with this too
> > > it will make 4 constructor versions for each geometry :!!
> > > 
> > > Just a note: when building a geometry with no defined factory
> > > current behaviour is to create a new Factory (which would leak
> > > unless deleted at geometry destruction time). If we decide to
> > > go with pointer-to-external-object we could use an
> > > internalGeometryFactory in thee cases.
> > > 
> > > --strk;
> > > 
> > > _______________________________________________
> > > geos-devel mailing list
> > > geos-devel at geos.refractions.net
> > > http://geos.refractions.net/mailman/listinfo/geos-devel
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at geos.refractions.net
> > http://geos.refractions.net/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
-- 
Ferdinando Villa, Ph.D., Associate Research Professor, Ecoinformatics
Gund Institute for Ecological Economics and Dept of Botany, Univ. of Vermont
http://ecoinformatics.uvm.edu