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
