What can you "new"
Unknown W. Brackets
unknown at simplemachines.org
Thu Mar 26 00:09:28 PDT 2009
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" <sean at invisibleduck.org> wrote in message
> news:gqdfse$1l38$1 at 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.
>
>
More information about the Digitalmars-d
mailing list