www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Side-Q: GC/ARC/Allocators - How many GC's

reply "Regan Heath" <regan netmail.co.nz> writes:
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/
Feb 04 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Feb 04 2014