C++, D: Dinosaurs?

[superdan]

Nick Sabalausky Wrote:

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

yeah. worked in hw design a long time. there ndas and all legal shit r tougher n easier to enforce. patent law applies keener to material shit. "accusing" is a bit much. just inferred an assessment based on ton's many other preposterous remarks. & his reaction when given attention.

ton may be working on googles next weird project fer all i know. assuming googles next weird project is a small one dood project given to an inexperienced youngster who don't compile in months don't know c++ macros suck don't ever runs into compilation time shit don't know processor speed hit a wall years ago don't understand dbc don't understand const don't understand modules don't understand what gc is good at. but has an opinion on all of the above. i suspect his nda has somethin' 2 do with mum suspending cookie rights.

but hang on. sure there's more fun stuff where that came from. my second fave after "don't compile in mos" is "i know too much about c++ to move do d and relearn stuff". this teen looks at spendin' his 401k golfing in peace already.