On Saturday, April 28, 2012 11:35:19 SomeDude wrote: > Right, I understand the situation better now. So basically, > what's needed is the custom allocators, and the GC would be > relieved from much of the work. That would still not work for > hard real time embedded, but for those applications, there are > lots of restrictions on memory anyway (no dynamic allocation for > once), so it wouldn't change much.
With custom allocators and/or shared pointers/references, you can pretty much avoid the GC entirely for classes as well as any structs that you put on the heap. So, you'd be in essentially the same place that C++ is for that. It's just arrays that you can't really fix. If you restrict yourself to what C/C++ can do with arrays (plus taking advantage of the length property), then you're fine, but if you do much beyond that, then you need the GC or you're going to have problems. So, as long as you're careful with arrays, you should be able to have the memory situation be pretty much identical to what it is in C/C++. And, of course, if you can afford to use the GC in at least some of your code, then it's there to use. I believe that the typical approach however is to use the GC unless profiling indicates that it's causing you performance problems somewhere, and then you optimize that code so that it minimizes its GC usage or so that it avoids the GC entirely. That way, your program as a whole can reap the benefits granted by the GC, but your performance-critical code can still be performant. Actually, now that I think about it, delegates would be another area where you'd have to be careful, since they generally end up having to have closures allocated for them when you pass them to a function unless that function them takes them as scope parameters. But it's easy to avoid using delegates if you want to. And if you want to program in a subset of the language that's closer to C, then you probably wouldn't be using them anyway. - Jonathan M Davis
