C++, D: Dinosaurs?

Tony tonytech08 at gmail.com
Thu Nov 6 13:07:18 PST 2008


"Nick Sabalausky" <a at a.a> wrote in message 
news:gergn9$109b$1 at digitalmars.com...
> "Tony" <tonytech08 at gmail.com> wrote in message 
> news:gerdem$rc4$1 at digitalmars.com...
>>
>> "Nick Sabalausky" <a at a.a> wrote in message 
>> news:gep0ej$232$1 at digitalmars.com...
>>> "Tony" <tonytech08 at gmail.com> wrote in message 
>>> news:geogvj$1p5r$2 at digitalmars.com...
>>>>
>>>> "Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
>>>> news:geo5p6$12gk$1 at digitalmars.com...
>>>>> Tony wrote:
>>>>>> (one HAS to use GC with D, right?)
>>>>>
>>>>> No. Well, the compiler generates calls to allocate & free memory, but 
>>>>> you can replace those calls with whatever you want. See Tango's 
>>>>> (druntime's) "stub" GC, which just reroutes compiler-generated calls 
>>>>> to GC methods to malloc() and free(). You can implement your own "GC" 
>>>>> or whatever management scheme you want (in fact, if you're writing, 
>>>>> say, a device driver in D, you would want to use a custom allocator 
>>>>> like this and not the built-in GC).
>>>>
>>>> Please clarify for me the mem mgmt of D: is the garbage collector 
>>>> optional or not?
>>>
>>> Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but 
>>> it's perfectly doable. I did it a few years ago when I was playing 
>>> around with using GDC with DevKitARM for GBA.
>>>
>>> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" 
>>> in the internal portion of phobos/tango/druntime or wherever it lives 
>>> now and comment-out the calls to "gc_init()" and "gc_term()". You might 
>>> also need to call "gc.disable()" or something (don't really remember). 
>>> And then if you still want to use "new" and/or "delete" with your own 
>>> memory manager, you can use D's class allocator and deallocator feature 
>>> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
>>> could probably plug those class allocators/deallocators directly into 
>>> the internal object class if you wanted.
>>
>> It sounds like a lot of work and new stuff to learn about the 
>> implementation. Let's face it, I'm not going to use D since it doesn't 
>> offer me anything over C++ that I want. The main thing I may like about D 
>> is that it makes the effort to make implementation of the language 
>> easier, and that, I think, is very key. I am here to look for features I 
>> would put in a new language, though that may be too large of an endeavor 
>> for someone my age.
>>
>> Tony
>>
>
> If you've already got your own full-fleged, reliable, memory management 
> system, plugging it into D via the methods Robert and I pointed out is 
> nothing by comparison.

If I could do something with the object model, and or if the compiler is 
open source, I would maybe look at the implementation as a potential 
starting point or learning tool. Every time I've considered using existing 
code though, I have ended up just starting with a clean slate for a number 
of reasons. For now, I'm going to evolve my framework a bit more and produce 
some programs. I'm keeping away from "advanced features" of existing 
languages as much as possible so as not to be tied to them. So far I've not 
found problem doing that. Error handling is the worst beast that I don't 
have completely slain yet. Generics and mem mgmt I have under control. I 
feel a bit limited by existing languages object models, that's probably the 
key reason why I'd like to invent a new language, be it for my own use or 
for more widespread use. Having full control of a language and it's 
implementation is nothing to sneeze at either, but taking advantage of that 
probably takes quite a bit of labor (more than one developer).

Tony 





More information about the Digitalmars-d mailing list