Hacker News Reader

Comment by blub | Hacker News Reader

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.

View on HN

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.

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.

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?

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.

Reply on news.ycombinator.com