FW: [geos-devel] Issues with smart pointers and threads?

Norman Vine nhv at cape.com
Wed May 28 18:40:47 EDT 2003


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
>




More information about the geos-devel mailing list