D Language 2.0

[Johan Granberg]

Andrei Alexandrescu wrote:

> 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

If allocating memmory with new in the no-gc module is causing trouble why
not disallow it so it becomes a compilation error. Programmers can use
object pools or no allocation strategys in these sections of their code.

I personaly would very much like a flag that disables allocations and
collections caused by code in selected modules. I was working on a class
project involving realtime physics simulation about a year ago and the gc
was a major source of slowdowns and some of the allocations was quite hard
to track down wasting a lot of time for me.

Thank you for your good work on the language thou, I don't want to come
across as to critical.

/Johan Granberg