Thanks, that's answering my question. In Objective-C as well as many other languages there is the feature to turn on Garbage Collection. It's a separate thread that scans memory for strong pointers, their source and origin and "vacuums" memory so to not have any leaks. Anything unreferenced and no longer needed is cleaned up automatically. There are some border cases where GC can fail, but for most it works. There are three values for the compiler: off, supported and required. One cannot mix subprojects unlike in e.g. ARC (Automated Reference Counting). Either it's on or off. Supported means that it covers both sides, "manual" memory management and automated management. As GC is an evolutionary stage across languages, objects formerly deallocated or freed or released (or whatever other term is used across different languages) through a unique call or method name where one would normally also host any steps to release associated resources not necessarily memory related (closing sockets, file handles etc.), such call is replaced with the language specific call that the garbage collector calls to still provide for closing these resources while still being able to handle memory management in an automated fashion. All directly memory related calls become no-ops to provide for backward compatibility. In the end one can compile with GC on, or GC off and the compiler refers to the calls it needs to deal with the two aspects accordingly, either resource-only management or resource-and-memory management. In general there are libs that provide garbage collection for C as well, like here: For example, it'd help avoid leaks like those caused by a result not being PQclear'ed. Alex Am 03.05.2012 um 09:16 schrieb Peter Bex:
|
