5 ms·

Well, before knowing about Obj-C memory management in detail I thought it was ok. Now that I know the rules it looks painful. If someone were to write such an

by blub 16y ago

Well, before knowing about Obj-C memory management in detail I thought it was ok. Now that I know the rules it looks painful. If someone were to write such an article about C, then it would have just one line: if you malloc, then you must free. If someone were to write such an article about C++, it would be more involved: delete if you new, delete[] if you new[] and then they'd explain auto_ptr and shared_ptr. More complicated that C, but still reasonably easy and you can get automatic memory management. On the other hand we have Objective-C, where you apparently need at least 11 paragraphs to explain the basics, only to find out that - yes - you still have to call malloc and free only with other names and slightly different behaviour?

rimantas 16y ago
A car is a horse only with other name and different behavior. If you new, alloc or copy, you own the object and must release it. Don't take ownership of delegates. That's about it.
btn 16y ago
The article is written in a condescending manner because the author is irritated. This means that it drags on a bit because of all the hand-holding through mundane examples. The rules are just as simple as C or C++, and Apple explains them far more succinctly: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html http://developer.apple.com/library/mac/#documentation/Cocoa/...
- blub 16y ago
  I don't mind that the author is condescending. However, I do not understand why C memory management is widely considered as difficult (there's a big trend to support GC nowadays to escape the "evil of malloc"), but Obj-C memory management is considered by the author as easy.
  - stuhacking 16y ago
    Objective-C memory management is still an abstract concept that has, as the root of it's mechanism, objects. You create an object, you release an object. C's memory management has a simplistic interface: malloc/free. However it operates on the notion of raw memory space. You need to do more work figuring out how much memory you need based on the size of your objects. C's memory management is not difficult, but it is more involved. The author says it pretty well when he states that Obj-C hits a middle ground between GC and manual memory management. It elevates the control of memory to a level where it makes more contextual sense.
  - dominostars 16y ago
    In ObjC I don't need to worry about whether someone else is using an object when I release it. Releasing an object doesn't free it unless no one else is retaining it. Dealing with this sounds like a nightmare in C.
  - demallien 16y ago
    Reference counting solves a number of otherwise difficult problems with the basic memory management of C. Yes, malloc and free are very simple operations, conceptually, but they are so low level that attempts to create a complex system without putting a layer of memory management over the top are generally destined to fail. Note that if you want, reference counting can be reduced to malloc/free - you simply use alloc/release instead of malloc/free - it's a direct substitution. But reference counting helps you for use cases that are more difficult. Here's a real life example that I ran into a few years ago when trying to write a largish system using just malloc and free. It was in the world of Conditional Access, and I was doing a cardless system that used a secure tunnel to talk to a server. I had an object that represented the Service Operator, and this object created the secure tunnel to talk with the server representing the service operator at the head-end. It worked just fine most of the time until I tried to handle the case of the command that deleted the representation of the Service Operator in my set top box. When I called Delete on the Service Operator object, my secure tunnel blew up, because it relied on information that was held by the Service Operator object. What I needed was a way of being able to say Delete the Service Operator object, but wait until the tunnel has closed before doing it. Now, you could just set a special flag in the tunnel object saying "delete the service operator after closing", or you could create a Service Operator callback that is called when the tunnel closes, and it doesn't act on any request to delete until that callback is received - but then what happens if someone other than the tunnel wants to delete the service operator? The callback never comes. It was a version of this system that I used in the end, but it was far more complicated than it would have been with reference counting. The solution when using reference counting is simply to a retain of the ServiceOperator when the tunnel opens, do a release when the tunnel closes, and if the tunnel really wants to delete the service operator, it does a release in mid-communication. As simple as can be.
    - blub 16y ago
      Thanks. Obj-C is better at sharing objects then. What if I create a custom malloc/free that keeps a share count at the beginning of the memory block, would that be similar?
dominostars 16y ago
The article complicates things by talking about 'autorelease' and '@property'. Neither of these concepts are necessary in understanding memory management in ObjC, they just add convenience to it.
- jonhendry 16y ago
  There are many, many methods that return autoreleased objects, which must be retained if you don't want your app to go boom, so I'd argue that autorelease should be covered. At least to the extent of explaining this. autorelease was added at the same time as the retain/release. @property, on the other hand, came much, much later and is entirely separate.
  - dominostars 16y ago
    I was just pointing out that you don't need to know autorelease is used if you just know to retain anything that isn't a new/init/copy/etc. Also, you don't need to use autorelease, you can just have all your variables return copies. Obviously it's something any Cocoa developer would want to learn, but it didn't seem necessary in an article trying to prove how basic memory management in ObjC is.
pornel 16y ago
For me "if you malloc, then you must free" is much harder, because you have to know whether ownership was passed to you, who else might be using object when you free it, etc. In Objective-C there's no owner, everyone borrows objects. You increase retain count (if you want to hold object for longer than lifetime of a function), and you decrease retain count when done. And there are few methods to increase (retain, init, copy, new, property assignent) and few to decrease count (release, autorelease, nil property assignment). To me it's that simple.
- schumihan 16y ago
  Reference count based GC? How would you deal with circular reference?
  - eru 16y ago
    You don't. You'd avoid creating circular structures as much as possible. You can get pretty far that way.
    - schumihan 16y ago
      It's very difficult to avoid it when thing goes complicating. A may reference B, B may reference C, ... and somewhere, X may reference back to A. If this strategy makes sense for big project, many hackers work with C++ can use it either, as the performance overhead is very low. But in the real world, reference-count based GC just has limited usage.
      - eru 16y ago
        > But in the real world, reference-count based GC just has limited usage. And in theory it doesn't fare much better. Proper garbage collection can have better performance, and does the Right Thing.
  - xsmasher 16y ago
    Retain your children but not your parents; or do you mean a group of "peers" who retain each other? They should probably be in some kind of collection that retains them All.
tzs 16y ago
> If someone were to write such an article about C, then it would have just one line: if you malloc, then you must free. That implies you cannot return malloc'ed memory to a caller in C. I doubt many people are willing to live under that restriction.
- Xuzz 16y ago
  Many C APIs do exactly that: they require you (the caller) to malloc your own memory, then pass in a pointer.
dgallagher 16y ago
The author didn't do a clear job explaining Obj-C's memory management. Apple on the other hand does: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html%23//apple_ref/doc/uid/20000994-BAJHFBGH http://developer.apple.com/library/mac/#documentation/Cocoa/... -------------------- In simplistic form: A) If a method "begins with" alloc or new, you must release or autorelease. B) If a method "contains" copy, you must release or autorelease. C) For every retain message you send to an object, you must balance it out with a release or autorelease (e.g. malloc/free). D) If a method returns an object to you, and the method name did not match with the "A" or "B" rules, you have received an autoreleased object. This object is guaranteed to exist for the remainder of its identifier's scope. E) To make an autoreleased object live longer than its identifier's scope, retain it (ensuring to release/autorelease it when finished). -------------------- There are a few edge scenario's too (described in the link), but that's the gist of it. Also, whenever you put an object inside an NSSet/NSArray/NSDictionary, it's sent a retain message. When said NSSet/NSArray/NSDictionary gets deallocated, it sends a "release" message to all of its members. A lot of other objects act similarly (always documented well by Apple). At first it's a little challenging to grasp. But after programming for a little while in Obj-C using the Foundation or Cocoa API, you get the hang of it and it comes quite naturally. In general I've found learning Obj-C with Foundation/Cocoa is difficult at first, mostly from trying to grasp the design patterns Apple has used with OOP. For example, delegate methods, bindings (using KVC/KVO), the responder chain, etc... But after you've learned them, you go "ah ha!!!" and get it. Then things become much easier to code. On top of that, I have nothing but good things to say about other Apple coders. From bloggers, to StackOverflow users, to IRC; everybody is extremely helpful and pleasant to deal with. :)

by blub 16y ago

rimantas 16y ago

A car is a horse only with other name and different behavior. If you new, alloc or copy, you own the object and must release it. Don't take ownership of delegates. That's about it.

btn 16y ago

The article is written in a condescending manner because the author is irritated. This means that it drags on a bit because of all the hand-holding through mundane examples. The rules are just as simple as C or C++, and Apple explains them far more succinctly: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html http://developer.apple.com/library/mac/#documentation/Cocoa/...

blub 16y ago
I don't mind that the author is condescending. However, I do not understand why C memory management is widely considered as difficult (there's a big trend to support GC nowadays to escape the "evil of malloc"), but Obj-C memory management is considered by the author as easy.
- stuhacking 16y ago
  Objective-C memory management is still an abstract concept that has, as the root of it's mechanism, objects. You create an object, you release an object. C's memory management has a simplistic interface: malloc/free. However it operates on the notion of raw memory space. You need to do more work figuring out how much memory you need based on the size of your objects. C's memory management is not difficult, but it is more involved. The author says it pretty well when he states that Obj-C hits a middle ground between GC and manual memory management. It elevates the control of memory to a level where it makes more contextual sense.
- dominostars 16y ago
  In ObjC I don't need to worry about whether someone else is using an object when I release it. Releasing an object doesn't free it unless no one else is retaining it. Dealing with this sounds like a nightmare in C.
- demallien 16y ago
  Reference counting solves a number of otherwise difficult problems with the basic memory management of C. Yes, malloc and free are very simple operations, conceptually, but they are so low level that attempts to create a complex system without putting a layer of memory management over the top are generally destined to fail. Note that if you want, reference counting can be reduced to malloc/free - you simply use alloc/release instead of malloc/free - it's a direct substitution. But reference counting helps you for use cases that are more difficult. Here's a real life example that I ran into a few years ago when trying to write a largish system using just malloc and free. It was in the world of Conditional Access, and I was doing a cardless system that used a secure tunnel to talk to a server. I had an object that represented the Service Operator, and this object created the secure tunnel to talk with the server representing the service operator at the head-end. It worked just fine most of the time until I tried to handle the case of the command that deleted the representation of the Service Operator in my set top box. When I called Delete on the Service Operator object, my secure tunnel blew up, because it relied on information that was held by the Service Operator object. What I needed was a way of being able to say Delete the Service Operator object, but wait until the tunnel has closed before doing it. Now, you could just set a special flag in the tunnel object saying "delete the service operator after closing", or you could create a Service Operator callback that is called when the tunnel closes, and it doesn't act on any request to delete until that callback is received - but then what happens if someone other than the tunnel wants to delete the service operator? The callback never comes. It was a version of this system that I used in the end, but it was far more complicated than it would have been with reference counting. The solution when using reference counting is simply to a retain of the ServiceOperator when the tunnel opens, do a release when the tunnel closes, and if the tunnel really wants to delete the service operator, it does a release in mid-communication. As simple as can be.
  - blub 16y ago
    Thanks. Obj-C is better at sharing objects then. What if I create a custom malloc/free that keeps a share count at the beginning of the memory block, would that be similar?

dominostars 16y ago

The article complicates things by talking about 'autorelease' and '@property'. Neither of these concepts are necessary in understanding memory management in ObjC, they just add convenience to it.

jonhendry 16y ago
There are many, many methods that return autoreleased objects, which must be retained if you don't want your app to go boom, so I'd argue that autorelease should be covered. At least to the extent of explaining this. autorelease was added at the same time as the retain/release. @property, on the other hand, came much, much later and is entirely separate.
- dominostars 16y ago
  I was just pointing out that you don't need to know autorelease is used if you just know to retain anything that isn't a new/init/copy/etc. Also, you don't need to use autorelease, you can just have all your variables return copies. Obviously it's something any Cocoa developer would want to learn, but it didn't seem necessary in an article trying to prove how basic memory management in ObjC is.

pornel 16y ago

For me "if you malloc, then you must free" is much harder, because you have to know whether ownership was passed to you, who else might be using object when you free it, etc. In Objective-C there's no owner, everyone borrows objects. You increase retain count (if you want to hold object for longer than lifetime of a function), and you decrease retain count when done. And there are few methods to increase (retain, init, copy, new, property assignent) and few to decrease count (release, autorelease, nil property assignment). To me it's that simple.

schumihan 16y ago
Reference count based GC? How would you deal with circular reference?
- eru 16y ago
  You don't. You'd avoid creating circular structures as much as possible. You can get pretty far that way.
  - schumihan 16y ago
    It's very difficult to avoid it when thing goes complicating. A may reference B, B may reference C, ... and somewhere, X may reference back to A. If this strategy makes sense for big project, many hackers work with C++ can use it either, as the performance overhead is very low. But in the real world, reference-count based GC just has limited usage.
    - eru 16y ago
      > But in the real world, reference-count based GC just has limited usage. And in theory it doesn't fare much better. Proper garbage collection can have better performance, and does the Right Thing.
- xsmasher 16y ago
  Retain your children but not your parents; or do you mean a group of "peers" who retain each other? They should probably be in some kind of collection that retains them All.

tzs 16y ago

> If someone were to write such an article about C, then it would have just one line: if you malloc, then you must free. That implies you cannot return malloc'ed memory to a caller in C. I doubt many people are willing to live under that restriction.

Xuzz 16y ago
Many C APIs do exactly that: they require you (the caller) to malloc your own memory, then pass in a pointer.

dgallagher 16y ago

The author didn't do a clear job explaining Obj-C's memory management. Apple on the other hand does: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html%23//apple_ref/doc/uid/20000994-BAJHFBGH http://developer.apple.com/library/mac/#documentation/Cocoa/... -------------------- In simplistic form: A) If a method "begins with" alloc or new, you must release or autorelease. B) If a method "contains" copy, you must release or autorelease. C) For every retain message you send to an object, you must balance it out with a release or autorelease (e.g. malloc/free). D) If a method returns an object to you, and the method name did not match with the "A" or "B" rules, you have received an autoreleased object. This object is guaranteed to exist for the remainder of its identifier's scope. E) To make an autoreleased object live longer than its identifier's scope, retain it (ensuring to release/autorelease it when finished). -------------------- There are a few edge scenario's too (described in the link), but that's the gist of it. Also, whenever you put an object inside an NSSet/NSArray/NSDictionary, it's sent a retain message. When said NSSet/NSArray/NSDictionary gets deallocated, it sends a "release" message to all of its members. A lot of other objects act similarly (always documented well by Apple). At first it's a little challenging to grasp. But after programming for a little while in Obj-C using the Foundation or Cocoa API, you get the hang of it and it comes quite naturally. In general I've found learning Obj-C with Foundation/Cocoa is difficult at first, mostly from trying to grasp the design patterns Apple has used with OOP. For example, delegate methods, bindings (using KVC/KVO), the responder chain, etc... But after you've learned them, you go "ah ha!!!" and get it. Then things become much easier to code. On top of that, I have nothing but good things to say about other Apple coders. From bloggers, to StackOverflow users, to IRC; everybody is extremely helpful and pleasant to deal with. :)