www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: C++, D: Dinosaurs?

reply superdan <super dan.org> writes:
Tony Wrote:

 
 "Nick Sabalausky" <a a.a> wrote in message 
 news:gevou0$15j4$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gevmuc$11hb$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message 
 news:gergn9$109b$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gerdem$rc4$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message 
 news:gep0ej$232$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...
 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 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."
Nov 07 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"superdan" <super dan.org> wrote in message 
news:gf1rhi$2ors$1 digitalmars.com...
 Tony Wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:gevou0$15j4$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message
 news:gevmuc$11hb$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message
 news:gergn9$109b$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message
 news:gerdem$rc4$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message
 news:gep0ej$232$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message
 news:geogvj$1p5r$2 digitalmars.com...
 "Robert Fraser" <fraserofthenight gmail.com> wrote in message
 news:geo5p6$12gk$1 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.
Nov 07 2008
parent superdan <super dan.org> writes:
Nick Sabalausky Wrote:

 "superdan" <super dan.org> wrote in message 
 news:gf1rhi$2ors$1 digitalmars.com...
 Tony Wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:gevou0$15j4$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message
 news:gevmuc$11hb$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message
 news:gergn9$109b$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message
 news:gerdem$rc4$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message
 news:gep0ej$232$1 digitalmars.com...
 "Tony" <tonytech08 gmail.com> wrote in message
 news:geogvj$1p5r$2 digitalmars.com...
 "Robert Fraser" <fraserofthenight gmail.com> wrote in message
 news:geo5p6$12gk$1 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.
Nov 07 2008