How many GC's do we get, if we build a D application linking it to a D library statically, or dynamically, or by loading it at runtime?

It seems to me, that one thing people really want in this discussion is to be able to select a single allocation strategy for their application, regardless of the libraries involved.

Is this at all technically possible?

I realise that if we had ARC, and GC, and manual memory management as 3 possible strategies on the table, and given that each would require different code/annotations then a library may be written for only say GC and simply wont work in the other modes.

But, could we design a system such that DMD can determine what allocation strategies are valid for a given library at link time.  It would require that libraries advertise this (in a separate file if necessary) although presumably they would or would not contain the required hooks as exported symbols for ARC or manual free if not built to support them so link would simply fail.

I admit I am not well versed in the details, but conceptually this could be powerful and flexible...

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Tuesday, 4 February 2014 at 13:52:53 UTC, Regan Heath wrote:
> It seems to me, that one thing people really want in this discussion is to be able to select a single allocation strategy for their application, regardless of the libraries involved.

I want:

1. To use full GC during start up and initialization for all objects that are going to live throughout "playmode".

2. To call CollectEverythingAndPauseGC

3. To use unique+shared+pools during "play mode" and no GC, except perhaps some kind of local GC.

4. To revert to full GC during "loadmode/savemode"

5. goto 2.

This is of course possible today, but not as convenient as it could be.