Hi Mark. You'll recall that I talked with you for quite a while at
Pg-day 2009 in Paris. Nice of you to chime in here.
> Except that Pg, via palloc, offers a way to clean up a whole memory context.
> Ensuring you delete your C++ object graph (probably via a few opaque
> pointers you pass around in the C code) when a MemoryContext is deleted
> isn't hard. palloc's MemoryContextMethods->delete_context provides just
> what's required. It's no different to what you do in a normal extension
> written in C, except that your deleteMyObject(somePtr) call happens to be an
> "extern C" function written in C++ that delete()s the ptr. No biggie.
>
> You can't do that if you're relying on smart pointers, refcounting,
> std::auto_ptr, etc because they're broken by longjmp, dtors won't get called
> when they should, you'll think objects are still referenced when they
> aren't, and things generally fail.
>
> It's even worse if you're relying on stack-based objects with dtors for lock
> management or the like.
>
That all seems very convoluted. Any non-trivial C++ class is either a
resource managing class, directly or indirectly. Therefore, all
non-trivial C++ classes on the stack are broken by longjmp(). You
can't use simple things like strings.
I just wish that it wasn't such a mess.
> It's not too tricky to just free your C++ object graph when a MemoryContext
> goes out of scope, as MemoryContexts have their own dtor-equivalents that're
> reliably called by Pg irrespective of setjmp/longjmp-based program flow. Why
> make it more complicated than it has to be? This way your dtors get called
> reliably at destruction.
I guess that's the least worst option at this time. You'll have to
pass ptrs to somewhere where they'll be subsequently be deleted.
They'll have to be typed. You'll have to write a bunch of utility
functions, one per class used, to preserve typing.
> That said, if I was to do that in code I was writing, I'd build a pool
> allocator based on a memory context that handed out palloc'd chunks... and
> I'd just give up on destructors for those objects.
>
> http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.10
> http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.14
>
Well, you still have the undefined behaviour problem, obviously. I
don't think that that's something that's ever going to be acceptable.
--
Regards,
Peter Geoghegan