API: C++ destructors should be usable

[blarg]

There are several places where the C++ API documentation says destructors should not be called, and supplies alternate de-allocator functions, for example ​http://www.gdal.org/classOGRSpatialReference.html#adda5434b145cd2728c907e74b795edcf and ​http://www.gdal.org/classOGRGeometryFactory.html#aae001086e26985d95c36ccd255a8c6d5

This is an unfortunate API convention, which greatly hinders use of several common C++ idioms, such as RAII. It would be much better if C++ destructors were usable in the usual way.

I believe I can guess what the original problem was, which prompted creation of these APIs (mixing runtime libraries on Win32 and consequently allocating instances in one heap, then attempting to deallocate them on another heap, yielding heap corruption and thus crashes). However I would rather not guess. Is there a ticket, RFC or mailing list thread about the problem(s) which prompted creation of these APIs?

If my guess as to the original problem is correct, then I think there exist superior solutions - specifically, creation of per-class 'operator delete' operator overloads.

In any case, a way should be found for developers to use the GDAL C++ API in the same way they use other C++ APIs and the usual way one writes C++, so the GDAL API does not appear strange and surprising to them.

[Even Rouault]

Yes that originates from cross-heap issues on win32

[blarg]

Yes, I guessed that, but rather than set up my own test case, I would rather re-create the original problem case that prompted creation of these APIs.

If the original problem case is lost in the sands of GDAL pre-history, that's fine :-) I have (sadly) encountered this sort of problem often enough that I can create it at will.

But if you know of an RFC, mailing list thread, or ticket about this, please share. I couldn't find anything, but maybe I was looking in the wrong places or the wrong way.

I would rather prove that I've solved the real-world problem which caused these APIs to be created, than show that I've solved an artificial problem of my own creation, which I claim (without proof) is isomorphic to the original real-world problem.

[blarg]

FYI, here's a good discussion of the details of C++'s 'operator delete', which is the best possible solution to this problem I've found so far:

​https://eli.thegreenplace.net/2015/c-deleting-destructors-and-virtual-operator-delete/

The other possible (partial) solution would be to ensure that constructors and destructors are always either a) all inlined, or b) never inlined. This would be significantly inferior, but perhaps still acceptable.

[blarg]

Er, and I would like to add, this is horrible C++ black magic. I do not pretend otherwise :-)

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.