Hm... how should I put it nicely... wait, I guess I can't: if you guys think D is a systems language, you are smelling your own farts!
Because 1) GC magic and deterministic system level behavior are not exactly good friends, and 2) YOU DO NOT HAVE A SYSTEMS PROBLEM TO SOLVE. C was invented to write an OS in a portable fashion. Now that's a systems language. Unless you are designing the next uber OS, D is a solution in search of a problem, ergo not a systems language (sorry Walter). It is a great application language though, and if people really need custom allocation schemes, then they can write that part in C/C++ or even assembler (and I guess you can provide a custom run-time too, if you really DO HAVE a systems problem to address -- like developing for an embedded platform). Here go another two pessos. "Sean Kelly" <s...@invisibleduck.org> wrote in message news:gqdfse$1l3...@digitalmars.com... > Cristian Vlasceanu wrote: >>>> Do custom-allocated objects live on the GC-ed heap? >>> Not necessarily, e.g. you can malloc some memory and then create an >>> object there. >>> >> >> I was afraid that may be the case, and it is perhaps not a good idea. > > I think this is unavoidable if D wants to be a "real" systems language, > because shared memory use is pretty common in such apps. D has this now > with custom new/delete methods, but if these are eliminated then there > would have to be some kind of substitute. They certainly wouldn't be > commonly used, but this has to at least be possible.
