D Language 2.0

[Andrei Alexandrescu]

BCS wrote:
> Hello Andrei,
> 
>> BCS wrote:
>>
>>> Also there is one thing that -nogc would have over what you are
>>> talking about; you could use it on some modules and not others. If I
>>> have some performance critical code where attempting to use the GC
>>> would break it's perf contract, I can put it in it's own module and
>>> compile just it with -nogc and then link it in with code that does
>>> use the GC.
>>>
>> Meh. This has been discussed in the C++ standardization committee, and
>> it gets really tricky real fast when you e.g. use together several
>> libraries, each with its own view of memory management. My impression:
>> don't.
> 
> 
> Why would having one chunk of code get checked for calls to the GC and 
> another not be any more complicated than mixing 
> malloc/free+add/removeRoot with normal GC? I'm beginning to wonder if 
> I'm calling for something different than other people are.
> 
> What I'm thinking of would have zero effect on the generated code, the 
> only effect it would have is to cause an error when some code would 
> normally attempt to invoke the GC.

It's much more complicated than that. What if a library returns an 
object or an array to another library?

Memory allocation strategy is a cross-cutting concern.


Andrei