[Top][All Lists]

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

Re: Automated Reference Counting (Was: Disappointed by GNUstep)

From: Fred Kiefer
Subject: Re: Automated Reference Counting (Was: Disappointed by GNUstep)
Date: Mon, 7 Feb 2022 21:21:58 +0100

> Am 07.02.2022 um 18:47 schrieb Wolfgang Lux <>:
>> Am 06.02.2022 um 19:50 schrieb Fred Kiefer <>:
>>> Am 06.02.2022 um 16:30 schrieb Wolfgang Lux <>:
>>>> There are bugs in GNUstep and probably there always will be. We don’t get 
>>>> enough testing, usage, for GNUstep gun applications, so many bugs may go 
>>>> unnoticed for a long time. At least the first bug you mention below is 
>>>> something I already fixed on Christmas. I am surprised that you are still 
>>>> seeing it. We may be slow at detecting bugs, but many issues get resolved 
>>>> shortly after being reported.
>>> maybe I should have spelled it out more clearly. I don't have that much of 
>>> a problem in general with my code crashing when I update to the latest 
>>> version of the tree, as long as isn't something that could easily be 
>>> avoided. And I've spent/wasted too much time debugging memory management 
>>> related bugs in Objective-C code (mostly outside the GNUstep libraries) so 
>>> that I've lost tolerance for such bugs these days. Therefore, I keep 
>>> pestering people with requests to switch to ARC when encountering such bugs.
>> Yes, ARC is a real improvement for application code. Not so much for 
>> libraries, as GNUstep is. Getting reference counting correct in procedural 
>> programming is not too hard in most case, but doing so declaratively just 
>> seems easier. You need to be very careful and provide the correct hints for 
>> the compiler to sort out things for you. I would expect that a switch here 
>> will cost us about two years until we got most of the declarations correct. 
>> Still the change would be worthwhile.
> I think you're making up an artificial difference here. The rules for 
> reference counting are the same for both application and libraries: If you 
> own/use an object retain it, once you no longer own/use it (auto)release it. 
> The tricky point just is avoiding cyclic references because they will never 
> be released.
> But the real problem (usually) starts when programmers start trying to 
> outsmart those simple rules by thinking that some object is already retained 
> by some other container/instance variable and they can save some extra CPU 
> cycles (plus the textual clutter) by omitting the retain/release calls. And I 
> know what I'm talking about because I often enough fall prey to this sort of 
> "optimization". But, as the issue with NSPopUpButtonCell shows, I'm not the 
> only one. Note that there is no semantic reason to use an unretained 
> reference for the _selectedItem instance variable.
> So for -gui the main issue is managing references between objects and their 
> delegates and avoiding cyclic reference between parents and children in the 
> view hierarchy. And otherwise not compromising the code by the attempting to 
> omit retain/release otherwise. For -base, the difficulty is not so much 
> cyclic references, but multithreading. You have to be even more careful about 
> retaining objects because -- at least without serious locking, which comes 
> with its own set of problems -- you cannot be sure that assumptions that hold 
> at entry of a method are still valid at the end. So, in a way I feel its even 
> the other way around: In libraries ypu should be very sure about proper 
> management of ownership, which is better done automatically, whereas in 
> applications you can eventually be more sloppy, for instance when you know 
> that the application is single threaded.

What you are describing is about what I wanted to say, but obviously failed to 
do. Things are a lot easier in an application as you know what you are aiming 
at. In a library you need to be correct for whatever use case people come up 
with. Doing that is hard. ARC may be able to help you in most cases. Still you 
will have to be very careful and you will need a lot more understanding of the 
implicit semantics. I agree that we should be going that route, we just need to 
be aware that it is a steep road and we need to be careful. Just as you said.


reply via email to

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