C++, D: Dinosaurs?
Tony
tonytech08 at gmail.com
Thu Nov 6 14:50:40 PST 2008
"Nick Sabalausky" <a at a.a> wrote in message
news:gevou0$15j4$1 at digitalmars.com...
> "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?
Avoiding yet another black box for one thing. I can't really disclose here
other reasons.
>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.
See, you think in terms of "What reason would there be not to use GC?"
whereas I think "For what reason would I want to use GC?". Either is OK,
just personal preference (well in moreso in C++ than in D).
Tony
>
>
More information about the Digitalmars-d
mailing list