Tony:
> Avoiding yet another black box for one thing.

Yes, that's a real problem. In practice to program effectively in D1 you have to read the source code of the GC (or use lot of documentation about the Phobos GC, but it's absent still).

Bye,
bearophile

Tony wrote:
> "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 
> 
> 

What exactly is your memory management system? Is it a GC? Is it pooling code? Is it a more efficient implementation of free/malloc?


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

"Bruno Medeiros" <brunodomedeiros+spam@com.gmail> wrote in message news:gf2967$opv$1@digitalmars.com...
> Tony wrote:
>> "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
>
> What exactly is your memory management system? Is it a GC? Is it pooling code? Is it a more efficient implementation of free/malloc?

I can't disclose those details, sorry.

Tony

Tony wrote:
> I can't disclose those details, sorry.

Either you're working for DoD, or you're trolling. If the entire point of your code were memory management, you would have said that, most likely, and would have no interest in D, unless you could base its garbage collector on your memory management system.

I can't fathom your purpose in posting here. You ask us for what D does better than C++ and immediately say that none of it applies to you, and imply that it's not worthwhile. D isn't the language for you. You've established that. Why are you still here?

Tony wrote:
> Please clarify for me the mem mgmt of D: is the garbage collector optional or not? Just allowing me to replace "getmorecore()" or something like that and then having the collector on top of that is unacceptable to me. I think you may be saying that dynamic memory is in every program, which again is not acceptable to me.

You can pretty much avoid all gc in D by doing your allocations using malloc/free and overloading operators new and delete for your classes. Some language features rely on gc, like dynamic closures, array concatenation, and the built-in associative arrays, but those features need not be used.


> Really, memory control is a key issue when choosing a language for me anyway. I require that level of closeness to the hardware. Anything less is too 4GL-like for me.

I understand how you feel. For a very long time, I felt the same way. I wanted the control. I thought GC was for below average programmers who couldn't handle memory allocation. I worked with a Java implementation for a while when Java first came out (building a native Java compiler) and came to realize the basis of my beliefs were unfounded.

GC has some compelling advantages:

1. GC programs can be faster

2. GC programs can use less memory

3. GC programs can be guaranteed to be memory safe

4. GC programs are faster to develop and have fewer bugs

Walter Bright wrote:
> I understand how you feel. For a very long time, I felt the same way. I wanted the control. I thought GC was for below average programmers who couldn't handle memory allocation. I worked with a Java implementation for a while when Java first came out (building a native Java compiler) and came to realize the basis of my beliefs were unfounded.

I feel obliged to mention Kris's presentation on garbage collection, "Array Slicing Fo' Shizzle" ( http://www.authorstream.com/Presentation/george-38229-Kris-Array-Slicing-foShizzle-Background-Java-Enigma-GC-Pressure-slic-Education-ppt-powerpoint/ ), mentions some issues with abusing a garbage collector. (Where are the videos for that? I thought they were released, but I don't see any links in the likely places.)

Hello Christopher,

> Walter Bright wrote:
> 
>> I understand how you feel. For a very long time, I felt the same way.
>> I wanted the control. I thought GC was for below average programmers
>> who couldn't handle memory allocation. I worked with a Java
>> implementation for a while when Java first came out (building a
>> native Java compiler) and came to realize the basis of my beliefs
>> were unfounded.
>> 
> I feel obliged to mention Kris's presentation on garbage collection,
> "Array Slicing Fo' Shizzle" (
> http://www.authorstream.com/Presentation/george-38229-Kris-Array-Slici
> ng-foShizzle-Background-Java-Enigma-GC-Pressure-slic-Education-ppt-pow
> erpoint/ ), mentions some issues with abusing a garbage collector.
> (Where are the videos for that? I thought they were released, but I
> don't see any links in the likely places.)
> 


http://video.google.com/videoplay?docid=-4010965350602541568&hl=en

The link is provided from this page:

http://d.puremagic.com/conference2007/speakers.html

I haven't actually watched any of these yet since I'm still on dialup. :P But I see that they can be downloaded as a mp4 file, so maybe I'll have a go at it.

-JJR

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:gf5r4l$2kt9$1@digitalmars.com...
> Tony wrote:
>> Please clarify for me the mem mgmt of D: is the garbage collector optional or not? Just allowing me to replace "getmorecore()" or something like that and then having the collector on top of that is unacceptable to me. I think you may be saying that dynamic memory is in every program, which again is not acceptable to me.
>
> You can pretty much avoid all gc in D by doing your allocations using malloc/free and overloading operators new and delete for your classes. Some language features rely on gc, like dynamic closures, array concatenation, and the built-in associative arrays, but those features need not be used.
>
>
>> Really, memory control is a key issue when choosing a language for me anyway. I require that level of closeness to the hardware. Anything less is too 4GL-like for me.
>
> I understand how you feel. For a very long time, I felt the same way. I wanted the control. I thought GC was for below average programmers who couldn't handle memory allocation. I worked with a Java implementation for a while when Java first came out (building a native Java compiler) and came to realize the basis of my beliefs were unfounded.
>
> GC has some compelling advantages:

To you and a bunch of others it does, you mean. "Compelling", to me, means something like "leapfrogs enough other issues or capabilities and/or in a nicer way" than what is currently available or what can be created.

>
> 1. GC programs can be faster
>
> 2. GC programs can use less memory
>
> 3. GC programs can be guaranteed to be memory safe
>
> 4. GC programs are faster to develop and have fewer bugs

None of which "sell me" on GC. But please don't "go there"! (I know that "to GC or not to GC" is a flamewar topic). Who knows, maybe my own memory management architecture (the reworked (new and improved! literally) version not yet in production, but soon) will evolve to be the backend to a garbage collector. As an independent developer, I have to keep my cards close to my chest about some of (one?) the reasons why I thing "my way" is compelling (in the true sense of the word). Gar bage collectors have a (some?) characteristic(s) that may indeed be deal breakers for some (a lot?) of software. That's why I think GC should be an opt-in rather than an opt-out choice. That's a key characteristic of C++: opt-in. And I really, really like that level of creative freedom. (Of course, in my own language, I'll do that even better than C++ does. :) Which is not to say though that I expect to replace C++. My language will be "higher level" (whatever that means) than C++).

Tony

"Tony" <tonytech08@gmail.com> wrote in message news:gflkav$8rc$1@digitalmars.com...
>
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gf5r4l$2kt9$1@digitalmars.com...
>>
>> 1. GC programs can be faster
>>
>> 2. GC programs can use less memory
>>
>> 3. GC programs can be guaranteed to be memory safe
>>
>> 4. GC programs are faster to develop and have fewer bugs
>
> None of which "sell me" on GC.

Why not? They sound like pretty darn good reasons to me. What are you expecting out of a memory manager, the secret of the universe?

If you have reason to disagree that the items on that list are true, then ok, I can understand. But if you're saying that those aren't good enough reasons, then it sounds like you have unrealistic expectations.

> As an independent developer, I have to keep my cards close to my chest about some of (one?) the reasons why I thing "my way" is compelling (in the true sense of the word).

I'm an independent developer too, but I have to say, this is a clear indication that your system isn't nearly as special as you think it is.

There are only three types of people who ever have a non-standard solution and think it's actually worth bothering with such secrecy: 1. Industry-renowned full-time tech researchers who actually do create good stuff (and then make it publicly known by the time their research is done), 2. Suits and managers, who don't know a damn thing about the technical side of anything, including code, and 3. Novices.

I'm not saying this to try to convince you to tell us, or to insult you, but as a cautionary tale. You need to take a good hard look at your system, be as objective as you can possibly be, and make sure it really is the that special. Because anytime you tell yourself "This is so good that nobody else has thought of it and it's the ace up my sleeve", that should raise a giant red flag in your mind saying that no, in fact, it's extremely doubtful that it's anything special at all.

Tony wrote:
> That's why I think GC should be an opt-in rather than an opt-out choice. That's a key characteristic of C++: opt-in. And I really, really like that level of creative freedom.

I've used a GC with C++ (both the Boehm one and one I wrote myself). The idea that GC is opt-in in C++ is ok for the user, but not for the library writer. The poor library writer, faced with supporting both GC and explicit allocation, winds up stuck with the worst of both. The problem is when calling new, you cannot tell which you're getting. That just throws a monkey wrench into designing portable software, because to effectively use GC entails writing code in a different way.