discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Tutorials enhancement proposal : First Steps in GNUstep GUI Programm


From: Patrick Cardona
Subject: Re: Tutorials enhancement proposal : First Steps in GNUstep GUI Programming (2) : NSWindow, NSButton
Date: Thu, 11 Jun 2020 21:01:30 +0200
User-agent: GNUMail (Version 1.3.0)

Hi David,

I looked around to better understand how to use ARC and the new ABI as you 
suggested.
But according to your article on the wiki (1), I understood that only 64bits 
systems could be able to use the new ABI : is it right ?

And the RPI 3B+ I am using now is only 32 bits :
description: ARMv7 Processor rev 4 (v7l)
    product: Raspberry Pi 3 Model B Plus Rev 1.3
    ...
    bits: 32 bits


(1) The Wiki source :
 http://wiki.gnustep.org/index.php/ObjC2_FAQ,


-- 
Regards,
Bien cordialement,
Patrick CARDONA
On 2020-06-10 12:44:06 +0200 David Chisnall <gnustep@theravensnest.org> wrote:

> On 10/06/2020 10:42, Patrick Cardona via Discussion list for the GNUstep 
> programming environment wrote:
>> Ref : First Steps in GNUstep GUI Programming (2) : NSWindow,  NSButton
>> Edition : First Edition: July 2000; Last Updated: January 2008
>> URL : http://www.gnustep.it/nicola/Tutorials/WindowsAndButtons/index.html
> 
>> Hi Nicola (Pero),
>> Hi All,
> 
>> I wish first to thank You, Nicola, for the great tutorials You made.
>> They helped Me to understand and begin my learning pretty well.
> 
>> Trying to play and understand the final code in the Tutorial 'First Steps 
>> in GNUstep GUI Programming (2) : NSWindow,  NSButton', I was facing to 
>> some warnings and bugs. I think You should modify the final code listing at 
>> page 9, in the '@implementation' section like this :
> 
>> (1) In the method 'dealloc' :
> 
>> - (void) dealloc
>> {
>>     RELEASE (myWindow);
>>     /* According to a warning while making the app */
>>     [super dealloc];
>> }
> 
> Note that this -dealloc method is not required at all with ARC.
> 
>> (2) In the method 'createWindow' :
> 
>> - (void) createWindow
>> {
>> ...
>> myWindow = [NSWindow alloc];
> 
>>     /* Don't make a assignment of 'myWindow' again...
>>     myWindow = */
>>     /* So I kept only the message... */
>>     [myWindow initWithContentRect: rect
>>                          styleMask: styleMask
>>                          backing: 
>> NSBackingStoreBuffered
>>                          defer: NO];
> 
>>    /* Here, the contentView was obviously missing : I added it... */
>> [myWindow setContentView: myButton];
>> ...
>> }
> 
> As Richard says, the semantics of init-family methods mean that this doesn't 
> do what you think it does.
> 
> An init-family method consumes the receiver and returns a new owning 
> reference to the return value.  In the common case, the the receiver will be 
> the same as the return value and so this cancels out.  In the case of things 
> like NSWindow, it is quite likely that they are different.  NSWindow +alloc 
> is likely to return a singleton placeholder and do the real allocation when 
> you call one of the init-family methods that
> 
> That is why it is considered good style to never assign the result of alloc 
> to a variable and always chain the call as [[SomeClass alloc] 
> initWithSomeInitFamilyMethod: ...].  For more information about method 
> families, see this:
> 
> https://www.informit.com/articles/article.aspx?p=1745875&seqNum=4
> 
> Note that without ARC, your version may generate memory management errors.  
> With ARC, it will just have surprising behaviour: the newly created window 
> created by the init-family method will be deallocated immediately and the 
> value assigned to myWindow will point to the placeholder.
> 
>> I Hope this could be helpful for other Beginners like Me. ;-)
> 
> I would *strongly* recommend any beginner use ARC from the outset. Thinking 
> in terms of ownership and consume operations is a far better memory model 
> than thinking in terms of reference count manipulation.
> 
> ARC also makes memory management work cleanly in Objective-C++, so things 
> like std::vector<NSMutableString*> work correctly (and will typically be 
> faster than NSMutableArray<NSMutableString*>).
> 
> David
> 
> 




-- 
Bien cordialement,
Patrick CARDONA




reply via email to

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