This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, Oct 19, 2011 at 1:13 AM, Basile Starynkevitch <basile@starynkevitch.net> wrote: > > Historically, it was the opposite: I do recognize the importance of garbage collection, > and because of the importance of Ggc in GCC, I designed MELT garbage collection above Ggc. > > > My strong belief is that any *big* compiler needs some automated way to deal with memory > (including circular references, which auto_ptr is not very happy about). It can be Ggc (I > am not very happy of it) or something else. > > But again, if many people (not me Basile) believe that Ggc is useless, why is it not > disappearing from the GCC trunk? > > And in my perception, auto_ptr are a poor man's way of implementing a garbage collection, > it is not a way to avoid it. > It seems that this thread needs some balance. Basile, I completely agree with you. I recommend people interested in automatic dynamic memory management to read this book: Garbage Collection: Algorithms For Automatic Dynamic Memory Management(Richard Jones,1996) The importance of garbage collection in large software project and why reference counting based solution is inefficient Âand can't be Âgood general "garbage collection" mechanism is clearly explained. As a non-compiler developer, I want to share my experience inÂstudying GCC's source code. When I first read GCC's source code several years ago, I was totally confused by the GGC markers here and there. Basically, I just don't understand their precise meaning. And I'm afraid I don't know how to add them. My source code analyzer(aÂproprietary software on Windows) was also confused/poisoned byÂtheÂGGC markers. The result is that I crafted a script that can remove nearly all(99.9%)ÂGGC markers in GCC source tree, then myÂsource code analyzer and I were both happy. I also attach the scripts. When not seeing theÂGGC markers, Âmy brain is much relaxed. ÂI can be more focused on the logic of compiler, don't worry about memory management issues. In this way, I found GCC's source code was not that horrible. ÂIt turned out to be simple and easy to understand "suddenly". My point is that, when a programmer don't need to worry about memory management issue, Âhis/her productivity isÂmaximized. -- Chiheng Xu
Attachment:
gcc_clean_scripts.tar.bz2
Description: BZip2 compressed data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |