i'm declaring two property inside my interface
both of them should be pointers, but xcode gives me two different errors..
// myClass.h
#import <Foundation/Foundation.h>
#class CCNode;
#interface myClass : NSObject
{
NSMutableArray myArray;
CCNode myNode;
}
for the NSMutableArray:
Interface type cannot be statically allocated
for the CCNode:
Field has incomplete type 'CCNode'
in both cases, using pointers will solve the issue, but what's the difference between them?
with try-and-error approach, i found out that if i change #class CCNode to #import "CCNode.h" then it gives me the same error as the first line, but i'm definetly missing something for the correct understanding....
what's the difference between them?
The compiler knows the full definition of NSMutableArray because its header file is included via the Foundation.h header. All it knows about CCNode is that it is an Objective-C class (thanks to the #class), not how big it is or anything else.
This is why including CCNode.h has the effect of changing the error, because the compiler now knows how big it is.
Pointers need to be declared with a *, so your declarations should look like this:
#class CCNode;
#interface myClass : NSObject
{
NSMutableArray *myArray;
CCNode *myNode;
}
#class is a forward declaration of your class. It has incomplete type because the compiler doesn't know how large it is, whether it's a struct, an object, a builtin type, etc. When you import the header, the compiler has all the info it needs.
In Objective-C, you can't allocate an object on the stack, so the point is kind of moot.
Objective-C requires that all objects are dynamically allocated (i.e. on the heap). The error you're getting indicates that you're trying to create a CCNode object on the stack. All Objective Class objects are pointer types.
Statically allocated variables are used for primitive C types like int or double
int marks=100;
Related
#class GSValue;
#interface GSValue : NSObject // Help the compiler
#end
#class GSNonretainedObjectValue;
#interface GSNonretainedObjectValue : NSObject // Help the compiler
#end
the above code from NSValue.m . i google and giving me some info, it indicate that #class(not accompanying with #interface) used for class forward declaration between two classes,but only declared as a pointer of the class. my question is why "#class GSValue;" immediately followed by "#interface GSValue:NSObject",what's the meaning?
I'm not quite sure, but i think in this case it's forward declaration + declaration, that GSValueand other classes are subclasses of NSObject. So, compiler won't give a warning when you write [GSValue class]. It's not actually "help", it's just to get rid of warnings.
Though, if this is the case then I don't know why they use forward declaration with #interface, cause it works just the same without #class directive.
I see it that way.
They used forward declaration in the first place. Then they noticed that compiler gives warnings Receiver 'GSValue' is a forward class and corresponding #interface may not exist, so they added #interface sections, but forgot or didn't bother to delete former #class directives.
I am learning Objective-C and was just curious. I can create an object of a NSString in these places, and please provide any others. To me they all do the same thing. I don't know what is the difference is between them. Where is it stored? From where can I access it? What are the advantages?
1)
// .h
#interface ...
#property (strong,nonatomic) NSString *text;
#end
2)
// .h
#interface ... {
NSString *text
}
#end
3)
// .m
#interface ... ()
#property (strong,nonatomic) NSString *text;
#end
First and foremost, my answer is based on the latest Clang compiler, older versions worked slightly different.
So, you're not creating an object in neither. You're not even declaring an object in two of them.
In the first case, you're actually telling the compiler that you need to expose a property called text of type NSString. What the compiler does, is declaring an instance variable for you _text (which you can access without a problem by the way) and the methods needed to get and set that instance variable. As you can see the storage is still internal, you just have getters and setters set for you.
In the second case you're actually declaring an instance variable (ivar) yourself, just as the compiler does with _text. It's accustom to prefix it with _. The storage is still internal. On top of that, you can't access your ivar from outside, since it has no getter or setter and the implicit declaration is #private.
In the third case, you create an anonymous category (thus the empty parentheses) which adds a property to your class. Storage for this is a little bit harder/longer to explain, if you are curious about it, you can search up the Apple docs, see what a category is and so on. You can only access your property from within your class in this case, which makes it somehow redundant (the getters and setters), you could have declared it as an ivar.
You can also declare your ivars like this:
#interface GenericViewController : UIViewController{
NSString * text;
}
#end
#implementation GenericViewController{
NSString * text;
}
#end
Both of the above have local storage and private visibility (can't be accessed from outside). The difference between the two is that instance variables declared in the implementation are implicitly hidden and the visibility cannot be changed with #public, #protected and #private. If you use those directives you won't get compiler errors but are ignored.
Is there any difference in doing
#class MyViewController;
rather than doing the normal import of the .h into the appdelegate.h
#import "MyViewController.h"
I've seen some example recently that use the #class way and wondered if there any differences.
thanks.
There is a big difference.
#class MyViewController;
Is a forward declaration for the object MyViewController. It is used when you just need to tell the compiler about an object type but have no need to include the header file.
If however you need to create an object of this type and invoke methods on it, you will need to:
#import "MyViewController.h"
But normally this is done in the .m file.
An additional use of forward declarations is when you define a #protocol in the same header file as an object that uses it.
#protocol MyProtocolDelegate; //forward declaration
#interface MyObject {
id<MyProtocolDelegate> delegate;
...
}
...
#end
#protocol MyProtocolDelegate
... //protocol definition
#end
In the above example the compiler needs to know that the #protocol MyProtocolDelegate is valid before it can compile the MyObject object.
Simply moving the protocol definition above MyObject definition would also work.
#class allows you to declare that a symbol is an Objective-c class name without the need to #import the header file that defines the class.
You would use this where you only need the class name defined for the purposes of declaring a pointer to the class or a method parameter of the class, and you do not need to access any methods, fields, or properties in the class.
It saves a minuscule amount of compile time vs the #import, and it sometimes helps avoid messy include circularity issues.
[And, as rjstelling points out, it's sometimes useful where you have interleaved declarations and you need to "forward declare" something.]
I have the following code
#import <UIKit/UIKit.h>
#import "SecondLevelViewController.h"
#class DisclosureButtonController;
#interface DisclosureButtonController : SecondLevelViewController {
NSArray *list;
DisclosureButtonController *childController;
}
#property (nonatomic, retain) NSArray *list;
#end
I can`t get what
#class DisclosureButtonController;
means.
Can anyone explain to me ?
It simply tells the compiler that DisclosureButtonController is a Class that is defined elsewhere.
If you remove it you should get an error at DisclosureButtonController *childController; because the compiler doesn't know what you want him to do at this line.
From Apple Doc Defining a class
The #class directive minimizes the amount of code seen by the compiler and linker, and is therefore the simplest way to give a forward declaration of a class name. Being simple, it avoids potential problems that may come with importing files that import still other files. For example, if one class declares a statically typed instance variable of another class, and their two interface files import each other, neither class may compile correctly.
EDIT: I just saw that the #class directive is superfluous there, because you are declaring this class at the next line. Maybe there was a #protocol that used the class in between #class and #interface. But in your special case you could remove it without problems. It's redundant.
I always thought that one cannot declare an object property in a category.
Until my partner did it in our app's code, and it seemed to work.
I went on a SO and Google binge to try to explain to him that no, Objective-C categories can only be used to add methods, not properties. I found questions such as:
Setting New Property In Category Interface Implementation (look at the accepted answer)
Can I add a property for a method not in my category?
But then I found this link on Apple's site that contains the following about the #property declaration:
A property declaration begins with the
keyword #property. #property can
appear anywhere in the method
declaration list found in the
#interface of a class. #property can
also appear in the declaration of a
protocol or category. (emphasis added)
I know that this doesn't work:
#interface MyClass ()
NSInteger foobar;
- (void) someCategorizedMethod;
#end
But this compiles:
#interface MyClass ()
#property NSInteger foobar;
- (void) someCategorizedMethod;
#end
My question is (a) what's the best practice here? and (b) is this something that is new to Objective-C 2.0, and instead of using a "real" iVar, it simply uses associative storage behind the scenes to make this work?
You have always been able to declare an #property in a category. What you couldn't do -- and still can't -- is declare storage for the property in the category, neither as an instance variable nor via `#synthesize.
However....
#interface MyClass () is not a category. It is a class extension and has a distinctly more specific role than a category.
Namely, a class extension can be used to extend a class's #interface, and this includes #properties that can be #synthesized (including synthesizing storage in the modern runtime).
Foo.h:
#interface Foo
#end
Foo.m:
#interface Foo()
#property int x;
#end
#implementation Foo
#synthesize x; // synthesizes methods & storage
#end
it simply uses associative storage
behind the scenes to make this work?
Nope -- it is a real instance variable. The modern runtime fixes the fragile base class problem.
#interface MyClass ()
NSInteger foobar;
- (void) someCategorizedMethod;
#end
The above doesn't work (as expected) because foobar is, effectively, a global variable.
If you change it to:
#interface MyClass () {
NSInteger foobar;
}
- (void) someCategorizedMethod;
#end
Then it'll work with the latest release of the llvm compiler (with the right flags, as #Joshua indicated in a comment).
Generally speaking, properties are nothing different from other methods. As long as the ivar used is available in the ordinary class, there is no problem at all. It's just syntactic sugar.
Things start to get more difficult if also the ivar is automatically created, as is possible in some configurations.
The main point here is that declaration of the ivar is independent from the property.
Assotiative storage is the solution.
Have a look at this post.