So what exactly is coming with extended C++ support?

[Ethan via Digitalmars-d]

On Tuesday, 30 September 2014 at 22:32:26 UTC, Sean Kelly wrote:
>
> Would delete on the D side work here?  Or the more current
> destroy()?  ie. is release of the memory a crucial part of the
> equation, or merely finalization?

Destruction of an object is *far* more important than releasing
memory. Our D code's memory usage is drops in an ocean, but it
can potentially hold on to resources that need to be destroyed in
special ways depending on middleware/threading usage.

Object.destroy() would do the job, but there's also a
fragmentation problem that creeps in to a GC solution like the
default D implementation the longer you have your application
running. We already encounter plenty of cache-incoherent code in
other areas of the codebase, and since one of my roles is to
evangelise D (so to speak) I'm aiming to keep it running fast and
avoiding as many stalls as possible. If I avoid the current
implementation's garbage collection, then memory allocated stays
in roughly the same region (some work that I did manage to do and
intend on submitting a pull request for allows a user to specify
a custom set of allocation functions, so all memory from core and
phobos goes through our supplied memory allocator).

Either way, it still comes down to a function call to free your
object which means you're stepping outside of the way the GC
natively does things.