discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should we split the project into two branches?


From: Max Chan
Subject: Re: Should we split the project into two branches?
Date: Tue, 15 Feb 2022 16:55:20 -0500

One of the features of ARC is weak pointers, which clears itself to nil once the referenced object is deallocated. Mac OS X 10.6.8 has a backported weak pointer (the one Derek mentioned) and iOS 4.3.5 does not support weak pointers at all. This self-clearing behavior of weak pointer is what requires library support.

Weak pointers would become very important when Blocks enters the scene, as they strongly captures all objects ever used in them including self unless explicitly told not to using weak references, and weak self becomes an important coding paradigm for Blocks. Then Blocks became the basis of closures in Swift, something that is heavily applied even in Swift Standard Library.

Sent from my iPad

On Feb 15, 2022, at 10:57 AM, H. Nikolaus Schaller <hns@goldelico.com> wrote:



Am 15.02.2022 um 15:10 schrieb Derek Fawcus <dfawcus+lists-gnustep-discuss@employees.org>:

I don't know about the level of changes needed in GCC, or about the
possibility of using an objC preprocessor, but it was possible to
build and deploy ARC using (including __weak references) code to 10.6.8.

As I recall one had to build against the 10.7 SDK, and then add an
extra package for the __weak support.

So in theory one could do something similar regarding the libobjc1 code.

DF

https://stackoverflow.com/questions/7696201/how-to-deploy-to-snow-leopard-with-arc-enabled
https://www.mikeash.com/pyblog/introducing-plweakcompatibility.html

Interesting. And I still wonder why ARC seems to need any library support.

In my understanding (which is certainly wrong) ARC is automatic reference counting.

Done by a static analysis of the source code. Done during compile time and not
during run time where the libs/frameworks would play a role. This is the reason why
I proposed to think about a preprocessor for standard-gcc to handle these rules and
pass everything unchanged.

AFAIR the most important memory management rules of ObjC 1.0 are:
-alloc and -copy* and -retain return a retained object which must be released before returning
from a method. Objects returned by a method must be (explicitly or implicitly)
retained+autoreleased.

Objects assigned to persistent store (instance vars) must be retained and the previous value
must be released before. This is (not necessarily) usually wrapped by a setter method.

These are not extraordinarily complex so I also tend to think that training is not well enough
if programmers struggle with them. But they obviously do.

Hm. Just some thought: is anyone is looking for a master's or PhD-thesis: would it be
possible to statically analyse retain/release/autorelease code to locate memory leaks
which come from not following these rules?

BTW note: Linux kernel also has trouble with non-automatic reference counting.
retain/release are called get and put there. E.g.:
But they don't have the nice autorelease-pool and the rule that most methods return
autoreleased objects and caller must retain them (they often return retained object
and caller must put them)...

--hns

reply via email to

[Prev in Thread] Current Thread [Next in Thread]