C++, D: Dinosaurs?

[superdan]

Tony Wrote:

> 
> "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.

translation: "im a 13 yo wannabe cutting my teeth at shit who tries to look interesting on the net."