[geos-devel] Smart Pointers solve all MM problems?

[Martin Davis]

Hmm...  I can't quite bring myself to believe it's this easy.  If memory management was simply a matter of implementing smart pointers, why have people spent so many years improving GC algorithms?

I'm not clear on whether you're saying that SmartPointers should include reference counting or not.  I believe there is a well-known problem with reference counting not handling circular chains of pointers.  I can think of situations in JTS where this might arise, since it build arbitrary graph structures to represent arrangements of edges.  On the other hand, JTS has an advantage in that it allocates lots of small objects to accomplish it's internal tasks, but they can all be freed when those tasks are completed.  Some kind of internal memory pool might be a good way to approach this.

Also, am I right in thinking that smart pointers don't help you if you have functions which alloc memory structures and return them? (Which happens all over JTS - e.g. in indexes and edge graph structures).

Please not that I'm not saying this is not a good idea - I'm just cautious about making a fairly crucial implementation decision without considering all the pros and cons.

Martin Davis, Senior Technical Architect
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis at vividsolutions.com  Web: www.vividsolutions.com


> -----Original Message-----
> From: Norman Vine [mailto:nhv at cape.com]
> Sent: Wednesday, May 28, 2003 3:41 PM
> To: geos-devel at geos.refractions.net
> Subject: FW: [geos-devel] Issues with smart pointers and threads?
> 
> 
> Oops ... This was meant for the list
> 
> > -----Original Message-----
> > From: Norman Vine [mailto:nhv at cape.com]
> > Sent: Wednesday, May 28, 2003 9:30 AM
> > To: Ferdinando Villa
> > Subject: RE: [geos-devel] Issues with smart pointers and threads?
> >
> >
> > Ferdinando Villa
> > >
> > > On Wed, 2003-05-28 at 03:51, Norman Vine wrote:
> > > > The beauty of the auto_ptr auto_ref approach is that once
> > > > you accept the fact that it works much of the memory allocation
> > > > deallocation bookwork is taken care of for you auto magically
> > > > by the compiler and is guaranteed to be done correctly in an
> > > > 'exception safe way', and in general the resulting code 
> is *much*
> > > > cleaner.
> > > >
> > >
> > > Just like Java! :)
> >
> > Oooh..  that is a good selling point I forgot to mention :-)
> >
> > >> Smart pointers are probably the only thing that NEVER
> > > gave me a headache in years and years of C++ coding. On 
> the other hand,
> > > back to the shared PrecisionModel thing, a precision 
> model is three
> > > doubles and an int... and the copy constructor does a 
> fabs and a couple
> > > assignments. Once the constructor and setScale are 
> inlined (please)
> > > constructing one shouldn't really be slower than 
> assigning a pointer and
> > > incrementing a counter - and would probably be faster 
> than doing that
> > > with locking. So I guess it's your call - particularly if 
> this is the
> > > only place in GEOS where this is needed.
> >
> > Actually 'Smart Pointers' would help GEOS in many places.
> >
> > IMO It would behoove us to make a GEOSbase type from which all
> > GEOS classes were derived and this base type would of 
> course be nothing
> > more then a templated 'smart pointer' class.
> >
> > This way we could just forget about memory deallocation as it would
> > all be elegantly handled for us, JLJ.  < Just Like Java >
> >
> > Cheers
> >
> > Norman
> >
> 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
>