[geos-devel] GeometryFactory argument in Geometry constructors

Thu Jul 8 18:02:05 EDT 2004

I had a discussion with Martin on the topic and we decided
to leave GeometryFactory ownership to the user, thus keeping
just a reference to external factory inside Geometry objects.
All deprecated constructors lacking a reference to a GeometryFactory
had been dropped. All internal GeometryFactory constructions has
been removed.

--strk;

On Sat, Jul 03, 2004 at 04:15:34PM +0200, strk wrote:
> I've checked documentation, and saw that GeometryFactory is indeed
> an unmutable Class. Once you create it you cannot modify it in any
> way. It seems thus cleaner to use reference-counted pointers for
> it. Probably the same thing holds true for Geometry themselves,
> as editing of them should happen through the GeometryEditor
> class that in turn might return a newly allocated geom.
> 
> I'll make some experimentations with reference counting...
> 
> --strk;
> 
> On Fri, Jul 02, 2004 at 11:49:18AM +0200, strk wrote:
> > Ok. I reverted GeometryFactory semantic to copy arg, to avoid
> > time shifts. 
> > 
> > I'm not sure about the possibility of making the top layer
> > transparent as users would still need to know what to do 
> > with GeometryFactories passed to Geometry constructors.
> > 
> > An example:
> > 	1: create factory
> > 	2: create geometry1
> > 	3: modify factory (precision model - for example)
> > 	4: create geometry1
> > 
> > In the described situation factory modification at line 3 would
> > modify geometry1 future behaviour unless it copied the passed
> > factory. Using shared pointer will help avoiding memory leaks
> > but will still require some semantic definitions.
> > 
> > --strk;
> > 
> > On Thu, Jul 01, 2004 at 11:12:00AM -0400, Ferdinando Villa wrote:
> > > 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
> > > 
> > > _______________________________________________
> > > 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