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