Disadvantages of building a compiler and library on top of a specific memory management scheme

Frustrated c1514843 at drdrb.com
Thu Feb 6 12:51:16 PST 2014


On Thursday, 6 February 2014 at 20:24:55 UTC, Andrei Alexandrescu
wrote:
> On 2/6/14, 12:01 PM, Frustrated wrote:
>> See the other post about this. scopeDeallocation meant to 
>> simply
>> signal that the scope of a has ended but not necessarily there
>> are no references to a.
>
> So that's a struct destructor.
>
> Andrei

Well, except it hooks into the memory allocation strategy.

I'm not saying that what I outlined above is perfect or the way
to go but just an idea ;)

If new had some way to pass an "interface" that contained the
allocation strategy details and one had the notation like

new!MyManualAllocator A;

then I suppose A's destructor could call MyManualAllocator's
"scopeDeallocator" method and you wouldn't need an implicit call
there.

In either case though, it is implicit and done behind the scenes
by the compiler.

But if it's done by the destructor then it is, in some sense,
"hidden" and it feels hard coded since we normally don't think of
the user being able to control how an object is able to destruct
itself. (usually this is done by the person that creates the
object type)

In some sense, destructors clean up their own mess they created
but not make assumptions about how they were created.

The problem then becomes, does new!MyManualAllocator A; flow
through and A uses MyManualAllocator internally or does it use
it's own or can we for A to use MyManualAllocator(or some other
allocator)?









More information about the Digitalmars-d mailing list