C++, D: Dinosaurs?

[Nick Sabalausky]

"superdan" <super at dan.org> wrote in message 
news:gf1rhi$2ors$1 at digitalmars.com...
> 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."

Or he's under a very strict NDA, or he's researching experimental memory 
management techniques. If you weren't exactly what you're accusing Tony of 
being, you'd have the experience to know that, for bettor or worse, 
ultra-strict NDAs are a common, standard occurance in most of the commercial 
world. I've been under a number of them myself.