Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The <code>alloc</code> method will allocate memory for a new object. But the <code>init</code> method might throw away that memory and return a completely different object. Or it might return <code>nil</code>. This is why you must always do <code>self = [super init]</code> when you override an <code>init</code> method.</p> <p><code>NSString</code> is one class that does this kind of thing all the time.</p> <p>I'm not exactly sure why the exception is happening, but I believe it could be ARC injecting code in between your two lines of code or something similar. Whatever it is, something is trying to act on the allocated object that has never been initialised, and this is a <em>huge</em> problem that can lead to all kinds of issues. Consider yourself lucky it threw an exception, sometimes it wont.</p> <p>The <code>NSString</code> class might not actually be a real class. It may contain almost no methods and almost no variables. All it has is a bunch of factory methods to create "real" string objects of some other class, and this is done using methods like <code>initWithFormat:</code>. So, by long standing convention alloc/init must always be done in a single statement and there are a handful of places where, usually for performance reasons, something will rely on this convention being used.</p> <p>Basically, objective-c is a language where you don't need to know <em>exactly</em> what is going on inside an object. You just need to know what messages can be sent to an object, and how it will respond. Anything else is undefined behaviour and even if you learn how it works, it is subject to change without notice. Sometimes the behaviour will change depending on circumstances that are completely illogical, for example you might expect the "copy" method to give you a copy of the object you send it to, and while this is the default behaviour, there are many cases where it will actually just return the same object with slightly different memory management flags. This is because the internal logic of the class knows that returning the same object is much faster and effectively identical to returning an actual copy.</p> <p>My understanding is <code>copy</code> sent to NSString may return a new object, or it may return itself. It depends on which NSString subclass is actually being used, and there isn't even any documentation for what subclasses exist, let alone how they're implemented. All you need to know, is that <code>copy</code> will return a pointer to an object that is perfectly safe to treat as if it was a copy even though it might not be.</p> <p>In a "proper" object oriented language like Objective-C, objects are "black boxes" which can intelligently change their internal behaviour at any time for any reason, but their external behaviour always remains the same.</p> <p>With regard to avoiding nesting... The coding style for Objective-C often does require extensive nesting, or else you'll be writing 10 lines of code when only 1 is really needed. The square brace syntax is particularly suited to nesting without making your code messy.</p> <p>As a rule of thumb, I turn on Xcode's "Page Guide at column" feature, and set it to 120 characters. If the line of code exceeds that width then I'll think about breaking it into multiple lines. But often it's cleaner to have a really long line than three short lines.</p> <p>Be pragmatic about it. :)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload