4 ms·

The problems start when you need to manage resources other than memory. Examples of things that require explicit clean up: -> Files -> Sockets -> Transactions

The problems start when you need to manage resources other than memory. Examples of things that require explicit clean up: -> Files -> Sockets -> Transactions The C++ resource model can be applied to all resources, not just memory. Garbage collection only "solves" memory management for you - often that's the least important resource that your program is managing.

pjmlp 14y ago
True, however you have mechanisms like using, with, try, scope, defer that GC enabled languages offer. C++ destructors benefit is that you don't forget to call such constructs.
- strictfp 14y ago
  Most (all?) of these cannot cope with trees of objects, plus that they leave the responsibility of destructing to the user of the object. So they are just as ugly as external locking. Problem is that very few people understand this, so they implement "using" and feel content. I would give an arm and a leg for RAII on the JVM.
  - pjmlp 14y ago
    > Most (all?) of these cannot cope with trees of objects You can if all "destructors" take care of also closing the internal resources, thus initiating a cascade process of the object owned by them. But you're right, this leaves the responsibility in the user's side. > I would give an arm and a leg for RAII on the JVM. At least they finally added the "using" concept. In a few more versions maybe they get to add values.
fauigerzigerk 14y ago
Or in other words, garbage collection only covers about 99.999% of all resource allocations/deallocations ;-)
- skrebbel 14y ago
  Patient0 said "the most important resources", not "the most frequently allocated resources".
  - fauigerzigerk 14y ago
    The most important resource is the one that we spend the most time managing and that is clearly memory.
orlandu63 14y ago
You don't need RAII to manage non-memory resources. All you need are first class functions.
- anonymousDan 14y ago
  Could you expand on this a bit? I'd be interested to see an example of what you mean.
  - zem 14y ago
    it's a ubiquitous pattern in ruby. this blog post uses a file open/close lifecycle manager as an example: http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ http://yehudakatz.com/2012/01/10/javascript-needs-blocks/
    - Evbn 14y ago
      That's more about coroutines than first class functions, and it is RAII, using a wrapper methodd for the actor/dtor instead of defining a class.
      - zem 14y ago
        it is not raii as i understand the term. there is no destructor involved in closing the file, there is just a function that opens the file, passes your code the handle, then closes it when you're done.
        bowyakka 14y ago
        Doesn't this amount to the same thing ?
        zem 14y ago
        it accomplishes the same purpose, but the filehandle gets closed explicitly, not when it goes out of scope and its destructor gets called.
_debug_ 14y ago
> often that's the least important resource that your program is managing I think you're right but wrong here : it may be the least important in a technical sense, but the sheer amount of developer productivity lost in manual memory management is very expensive (for both the mental resources of the programmer and the firm), and this makes automated memory management a key positive. Honestly, my eyes glazed over to avoid traumatic memories of C++ and Windows DOM internals as I read the article. I have a LIFE since I moved to Java.

pjmlp 14y ago

True, however you have mechanisms like using, with, try, scope, defer that GC enabled languages offer. C++ destructors benefit is that you don't forget to call such constructs.

strictfp 14y ago
Most (all?) of these cannot cope with trees of objects, plus that they leave the responsibility of destructing to the user of the object. So they are just as ugly as external locking. Problem is that very few people understand this, so they implement "using" and feel content. I would give an arm and a leg for RAII on the JVM.
- pjmlp 14y ago
  > Most (all?) of these cannot cope with trees of objects You can if all "destructors" take care of also closing the internal resources, thus initiating a cascade process of the object owned by them. But you're right, this leaves the responsibility in the user's side. > I would give an arm and a leg for RAII on the JVM. At least they finally added the "using" concept. In a few more versions maybe they get to add values.

fauigerzigerk 14y ago

Or in other words, garbage collection only covers about 99.999% of all resource allocations/deallocations ;-)

skrebbel 14y ago
Patient0 said "the most important resources", not "the most frequently allocated resources".
- fauigerzigerk 14y ago
  The most important resource is the one that we spend the most time managing and that is clearly memory.

orlandu63 14y ago

You don't need RAII to manage non-memory resources. All you need are first class functions.

anonymousDan 14y ago
Could you expand on this a bit? I'd be interested to see an example of what you mean.
- zem 14y ago
  it's a ubiquitous pattern in ruby. this blog post uses a file open/close lifecycle manager as an example: http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ http://yehudakatz.com/2012/01/10/javascript-needs-blocks/
  - Evbn 14y ago
    That's more about coroutines than first class functions, and it is RAII, using a wrapper methodd for the actor/dtor instead of defining a class.
    - zem 14y ago
      it is not raii as i understand the term. there is no destructor involved in closing the file, there is just a function that opens the file, passes your code the handle, then closes it when you're done.
      - bowyakka 14y ago
        Doesn't this amount to the same thing ?
        zem 14y ago
        it accomplishes the same purpose, but the filehandle gets closed explicitly, not when it goes out of scope and its destructor gets called.

_debug_ 14y ago

> often that's the least important resource that your program is managing I think you're right but wrong here : it may be the least important in a technical sense, but the sheer amount of developer productivity lost in manual memory management is very expensive (for both the mental resources of the programmer and the firm), and this makes automated memory management a key positive. Honestly, my eyes glazed over to avoid traumatic memories of C++ and Windows DOM internals as I read the article. I have a LIFE since I moved to Java.