C++, D: Dinosaurs?

[Nick Sabalausky]

"Tony" <tonytech08 at gmail.com> wrote in message 
news:gevmuc$11hb$1 at digitalmars.com...
>
> "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

Out of curiosity, what benefits are you going for by using your own memory 
management system instead of just a built-in GC? From some of your comments 
in this thread, I'm guessing it has to do with either game development or 
limited-memory/speed embedded devices (or both in the case of handheld or 
retro gaming). I can see how those could provide reasons for a custom memory 
manager.