[Gdal-dev] GDAL 1.2.1 Released

[Mladen Turk]

Frank,

> From: Frank Warmerdam
> 
> It can be avoided by building GDAL and the application with a runtime
> C library.  I think this is accomplished with the /MD switch.
> 

True, but MFC still has a separate heap so the same problem again :(.

> The other approach is to provide some sort of external destructor access
> via exact function entry points.  I have done this already for many GDAL
> and
> OGR objects.  In particular for GDAL it is usually sufficient to call
> GDALClose()
> on a dataset handle to clean things up.
> 

Perhaps adding some tin root 'Object' for each public API class, like:
class OGRObject {
public:
	OGRObject() {};

	virual void Destroy(OGRObject *o) = 0;
};

Then you can have:

class OGRLayer : public OGRObject ...
and,
void OGRLayer::Destroy(OGRObject *o)
{
	delete (OGRLayer *)o;
}

That will force that each inherited class implements the Destroy method.


> I would like to also rewrite the MapServer mapogr.cpp code to use
> the
> OGR C API instead of the C++ API.

Excellent (after all mapserver is all plain C).

MT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3085 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20040624/17875a96/smime.bin