Thread: C++ Garbage Collector

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    *shrug* It was directed at my reply where I said no memory leaks. I originally did not include that definition of a leak or scenario when I wrote the reply, so we can consider them as separate issues that can cause "leaks" or other issues despite smart pointers.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,398
    Quote Originally Posted by Elysia View Post
    Ah. That is not a leak, however. It's just you using more and more resources and not letting the program free them.
    It's a good example that you need to be careful with your resource allocation, but it's not the fault of the smart pointers; it's yours.
    You seemed to be making the claim that a program which uses smart pointers can't contain memory leaks. That's just not correct.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #18
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Well, if my replies make it seem like that, then I apologize. Of course it's not the case.
    Smart pointers is a tool to help avoid memory leaks; it's not a bullet proof solution.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #19
    The larch
    Join Date
    May 2006
    Posts
    3,573
    I wonder if GC would do anything about it (how does it know it will not be used, seeing as it is in scope)?
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  5. #20
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,398
    Quote Originally Posted by anon View Post
    I wonder if GC would do anything about it (how does it know it will not be used, seeing as it is in scope)?
    GC cannot solve this problem. The problem doesn't come from reference counts, it comes from the references themselves. No garbage collector, unless it can predict the future, can know whether or not a reference to some object will ever actually be used.

    IOW, you should not have references in the root set which are never going to be used. Only the programmer can know that. Smart pointers and garbage collections aren't magical memory-leak-preventers, they are just a way to avoid the tedium of manual resource management. (And viewing either of them as an excuse to be lazy and not think about the problem is completely misinterpreting their purpose)
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #21
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    Quote Originally Posted by brewbuck View Post
    I've dealt with this before by slightly modifying the shared_ptr<>. Each pointer appends a pointer to itself (pointer to shared_ptr) onto a global list of pointers when it is created, and removes itself from the list when it is destroyed. This means that at any moment I have access to a list of all the shared_ptr objects in memory.

    At the end of the program, right before returning from main(), the list will contain only those pointers which still have positive refcounts, i.e. they point to blocks of memory which are referenced somehow. I know that I am about to terminate, so there is no valid reason these references should still exist -- therefore they are leaks. So I traverse this list and increment the refcount of each pointer in the list. Now the memory blocks will not be deleted and memcheck can report them.
    Reading this topic I was thinking of this exact solution. Transverse the list of all shared_ptr's and check refcounts. However, how did you get a list of shared_ptr's when they are templated? There's no generic containers (without casting). std::list<boost::shared_ptr<int>* > only works for int's, std::list<boost::shared_ptr<std::string>* > for std::string, etc. Did you void* cast? std::list<void*>
    Warning: Have doubt in anything I post.

    GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101

  7. #22
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,398
    Quote Originally Posted by Dae View Post
    Reading this topic I was thinking of this exact solution. Transverse the list of all shared_ptr's and check refcounts. However, how did you get a list of shared_ptr's when they are templated? There's no generic containers (without casting). std::list<boost::shared_ptr<int>* > only works for int's, std::list<boost::shared_ptr<std::string>* > for std::string, etc. Did you void* cast? std::list<void*>
    No, I implemented shared_ptr<> from scratch. It derives from a basic ref_counted class. So what I store in the list is pointers to ref_counted bases, not the actual shared_ptr<> types themselves.

    It's obviously more difficult if you are using some third-part smart pointer which you don't want to modify.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  8. #23
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    Quote Originally Posted by brewbuck View Post
    It's obviously more difficult if you are using some third-part smart pointer which you don't want to modify.
    Ya, unless you copy the source, rename it like gc_ptr or garbage_ptr, then modify and use that instead. I guess there's no possible way to transverse the list and delete objects which have died (have a refcount of one), because there's no way to store a list of ANY pointer (generic), and ALSO be able to know it's type when it comes to deleting it. Unless of course your smart pointer only accepted basic types, and/or types which inherit a base class (ie. class something : public garbage_collectable; boost::gc_ptr<something> s), or implement certain variables/functions (ie. typedef my_type).

    For you purposes though, debugging the list of pointers, it sounds like it works perfectly.
    Warning: Have doubt in anything I post.

    GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101

  9. #24
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    Quote Originally Posted by brewbuck View Post
    The variable x is never used, so its memory is wasted. This is called a "leak" under most definitions of "leak" I've ever seen. Reference counts can't help you if you maintain references to objects you will never use again.
    I definitely wouldn't call that a leak. Bad memory management? Error? Certainly.

    But for a true memory leak, the program must be in a state where it CANNOT free the memory (for example, if it lost all pointers to a dynamically allocated object). In the other case, the program still has the ability to free the memory, it just hasn't done so.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  10. #25
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,398
    Quote Originally Posted by Cat View Post
    I definitely wouldn't call that a leak. Bad memory management? Error? Certainly.

    But for a true memory leak, the program must be in a state where it CANNOT free the memory (for example, if it lost all pointers to a dynamically allocated object). In the other case, the program still has the ability to free the memory, it just hasn't done so.
    Because... that's what you say?
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #26
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    There is file leaks too, xP

    They exists because of:
    1. Abnormal processes
    2. Abnormal terminations
    3. You might forget about it

    1)
    Code:
    int *i = new int[10];
    .
    .
    throw ...
    2)
    Code:
    Ctrl+Alt+Del
    3)
    Code:
    int *i = new int[10];
    .
    .
    return; //no delete
    While
    Code:
    int *i = new int[10];
    
    for(;;);
    is exactly undefined behaviour I think. xD
    Just GET it OFF out my mind!!

  12. #27
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,728
    Quote Originally Posted by audinue
    There is file leaks too
    What do you mean by file leaks? The first and third examples that you cited can be considered memory leaks.

    Quote Originally Posted by audinue
    is exactly undefined behaviour I think.
    I think the behaviour is well defined: control goes into an infinite loop.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  13. #28
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by Cat View Post
    But for a true memory leak, the program must be in a state where it CANNOT free the memory (for example, if it lost all pointers to a dynamically allocated object). In the other case, the program still has the ability to free the memory, it just hasn't done so.
    There was an article years ago that classified the various kinds of leaks one could have in a Java program. I regularly supplied it to Java newbies who proudly proclaimed that Java had "eliminated" them, freeing them from having to "worry about memory management". I believe said article classified this kind as a "loiterer". Just hanging around with nothing better to do. :-)

    Been years...could be wrong about that.
    Last edited by medievalelks; 08-16-2009 at 07:25 AM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Garbage Collector, Managed Heap etc.
    By mynickmynick in forum C Programming
    Replies: 2
    Last Post: 08-07-2008, 12:42 PM
  2. Garbage Collection is not so complicated
    By Nalpdii in forum C Programming
    Replies: 2
    Last Post: 10-07-2007, 11:34 PM
  3. Garbage Collection
    By Orborde in forum C++ Programming
    Replies: 4
    Last Post: 05-10-2005, 11:18 PM
  4. Pointers and garbage collectors
    By Morglum in forum C++ Programming
    Replies: 0
    Last Post: 06-22-2002, 02:43 AM