[geos-devel] GeometryFactory argument in Geometry constructors

Ferdinando Villa ferdinando.villa at uvm.edu
Thu Jul 1 11:04:07 EDT 2004


Sorry for not having answered previous aclocal-related questions - I was
away. Anyway, I didn't have a clue....

Although I have essentially no time until August or so, I can volunteer
to implement a reference counted smart pointer layer over the current
geos in late summer. That can be done by including the necessary parts
of the boost library (not much) and can be implemented entirely on top
of the existing API, declared in a different namespace. We can subclass
a boost::shared_ptr to a geometry class that can be used with value
semantics, just like an int, and give access to all public methods of
the geometry pointed to. Users will be able to select implementations by
just switching namespaces. I can show examples of this usage in
unrelated code if you want me to - it's a totally fabulous way to work
once it's done. It's thread safe, too, if a reliable smart pointer
implementation is used. And I've been using boost for years in
multithreaded servers without a problem.
The other advantage is that all this is implementable in header files
only, so no library change is required.

Let me know if this sounds good and I'll put it in my priorities. 
Ciao f

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




More information about the geos-devel mailing list