garbage collection enabled c++

This is a discussion on garbage collection enabled c++ within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by brewbuck Not only will this code suck, it will be unusable on compilers that don't implement GC. ...

  1. #31
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,532
    Quote Originally Posted by brewbuck View Post
    Not only will this code suck, it will be unusable on compilers that don't implement GC.
    Well, that's more or less exactly what standardization tries to avoid. I don't see a problem there. GC won't be any different from any other feature part of the standard.

    What I doubt is that it ever sees the light of the day. My reasoning is that everybody (right?) agrees threads should be a part of the standard. And yet we all have been witnessing how hard it has been for an agreement to be reached on exactly how to implement them. Well, GC adds to all the implementation issues, the fact not everybody thinks it should be part of the standard in the first place.

    EDIT: Which actually leads me to one question... Is it possible for a program under C++ to implement its deallocation strategy with a combination of GC and RAII? That is, to choose the method on an allocation basis? Would this be desirable?
    Last edited by Mario F.; 02-15-2008 at 11:17 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #32
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    With the current library-based solutions, it's possible. Use the normal allocation for memory you want to manage manually, and use the GC library's allocator for things you want freed automatically.

    You may have to inform the GC library of the new root areas, though, if any manually managed objects contain pointers into the GC's memory area.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #33
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    Any way you look at it, GC would add additional overhead which can be avoided with smart pointers or RAII. Yes, they have some overhead too, but less so than GC.
    I don't see how how it can release and destruct objects properly (as in at the right time) unless called synchronously at the end of functions or blocks?
    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. #34
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Elysia View Post
    Any way you look at it, GC would add additional overhead which can be avoided with smart pointers or RAII. Yes, they have some overhead too, but less so than GC.
    That's a somewhat naive view of the situation. The fact that GC typically makes many deallocations at every pass means that it can greatly reduce the overhead of managing the heap data structures. GC has been known to outperform naive manual memory management.

    I don't see how how it can release and destruct objects properly (as in at the right time) unless called synchronously at the end of functions or blocks?
    Sometimes, you just don't care about when objects are destructed. For other situations, GC needs to be worked around, as evidenced by Java's finally blocks and C#'s IDisposable interface.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #35
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,532
    Quote Originally Posted by CornedBee View Post
    With the current library-based solutions, it's possible. Use the normal allocation for memory you want to manage manually, and use the GC library's allocator for things you want freed automatically.

    You may have to inform the GC library of the new root areas, though, if any manually managed objects contain pointers into the GC's memory area.
    Well, then. Not so bad to have I guess for those rare instances where GC may be beneficial. Still, IMHO, GC is non essential as part of the standard. It can - and probably should - be used by means of 3rd party libraries, as it has been so far. NO one died from GC starvation that I know of.

    Meanwhile I finally found the bloody article I couldn't find. (I sometimes wished I wasn't so hasty in moving on before deciding to bookmark or not some of the stuff I read.)

    http://www.pluralsight.com/blogs/hsu...1/23/3666.aspx
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #36
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    Quote Originally Posted by CornedBee View Post
    That's a somewhat naive view of the situation. The fact that GC typically makes many deallocations at every pass means that it can greatly reduce the overhead of managing the heap data structures. GC has been known to outperform naive manual memory management.
    That actually made me think of trying to find a way to run destructors when memory should be disposed but not freeing the memory. The memory could be freed in blocks later.
    I wonder if it's safe to run destructors first and then just use free? I wouldn't think it's safe, though.

    Sometimes, you just don't care about when objects are destructed. For other situations, GC needs to be worked around, as evidenced by Java's finally blocks and C#'s IDisposable interface.
    But the problem is that it might not always be safe to do so and that, I think, might be one of the main problems with GC.
    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.

  7. #37
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I wonder if it's safe to run destructors first and then just use free? I wouldn't think it's safe, though.
    Only if you used malloc to allocate the memory and then placement new for construction.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #38
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    I suppose you can override the allocation function with your own then, and allocate using malloc and construct using placement new.
    And so I could simply run the destructors when the memory needs to be deleted and free all memory in blocks.
    How efficient will it be, though?
    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.

  9. #39
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Well, you'd need internal knowledge of the allocator to actually make use of the fact that you're freeing in bunches.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #40
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    But then... you might need to make a custom deallocator or something? Since every call to the HeapFree function might just incur the big overhead.
    I guess it's a big project, after all.

    But it did give me an idea... It might be possible to route allocation through VirtualAlloc for Windows and then decommit a range of virtual memory. Would be faster, I guess.
    Only problem is that it wouldn't be portable. Meh.
    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.

  11. #41
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by Mario F. View Post
    Well, that's more or less exactly what standardization tries to avoid. I don't see a problem there. GC won't be any different from any other feature part of the standard.
    GC is notoriously hard to get right -- in fact, it's hard to even define what "right" is, in a way that everybody is happy with. After the struggle to get templates implemented everywhere (still in progress) I really don't see GC being implemented in a dependable way on a usable number of platforms for probably a decade at least.

    Invariably, implementations will have different behavior in the undefined areas, and people are going to rely on specific behavior even though they're not supposed to. And code is going to fragment even more into "only supported on compilers X, Y, Z."

    Every time I've experimented with GC I've ended up thinking "What the heck am I doing this for?" and just go back to RAII and object-owner containers.

  12. #42
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,532
    Quote Originally Posted by brewbuck View Post
    GC is notoriously hard to get right -- in fact, it's hard to even define what "right" is, in a way that everybody is happy with.
    Yes, I alluded to this on the same post you quoted.

    Every time I've experimented with GC I've ended up thinking "What the heck am I doing this for?" and just go back to RAII and object-owner containers.
    However, there seems to be uses for it under C++. I'd say, in my ignorant best, programming areas where every clock cycle counts and where delaying deallocation is not a problem. But, again, gc libraries can do that already. Adding gc to the standard seems a little odd; standardizing a practice that is not common and for which the language was not designed for.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  13. #43
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    Quote Originally Posted by Elysia View Post
    But then... you might need to make a custom deallocator or something? Since every call to the HeapFree function might just incur the big overhead.
    I guess it's a big project, after all.

    But it did give me an idea... It might be possible to route allocation through VirtualAlloc for Windows and then decommit a range of virtual memory. Would be faster, I guess.
    Only problem is that it wouldn't be portable. Meh.
    And you'd be demonstrating "Premature Optimisation" beautifully!
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Garbage Collection is not so complicated
    By Nalpdii in forum C Programming
    Replies: 2
    Last Post: 10-08-2007, 12:34 AM
  2. C++ Garbage Collection
    By vaibhav in forum C++ Programming
    Replies: 1
    Last Post: 11-27-2005, 10:26 AM
  3. Garbage Collection
    By Orborde in forum C++ Programming
    Replies: 4
    Last Post: 05-11-2005, 12:18 AM
  4. SDL: Garbage collection (?) screwing me
    By Brian in forum Game Programming
    Replies: 4
    Last Post: 05-08-2005, 10:13 AM
  5. garbage collection
    By joed in forum C Programming
    Replies: 4
    Last Post: 04-01-2004, 01:47 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21