D is better as a language, imho. You never know when Apple will scrap
Mac OS X and do a new operating system. Who knows, maybe iPhone OS 5.0
will be written in D? It's extremely improbable, but it's not impossible.
Allocators have many uses. When integrating (as with a plugin) into
other software, you may want/need to use their allocator - e.g. writing
a Firefox NSPlugin. Certainly not something I want to lock myself out
of using D for.
Embedded devices are definitely an interesting realm as well, and it's
definitely preferable to have one language and one compiler to have to
deal with in such situations. Assembly is a definite option, but custom
allocators are a cleaner way to do the same thing - otherwise I'd just
be using mov, div, inc, stosb, and the like, no?
-[Unknown]
Cristian Vlasceanu wrote:
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.
