I just spent some time finding out why a mutable set didn't correctly intersect itself
with another set, using
[someMutableSet intersectsSet:anotherSet]; // not the best idea
Of course, the correct syntax is [someMutableSet intersectSet:anotherSet] and the above line means something different – it's an method call with return value of BOOL type.
Since I have -Wall -Wextra options enabled this should have been caught as a warning. But it wasn't caught. I investigated further by trying, where types is an NSMutableSet:
(void)[types intersectsSet:types]; // -> no warning, this is expected
(BOOL)[types intersectsSet:types]; // (1) -> warning, this is expected
And, again, if I do this:
[types intersectsSet:types]; // (2) -> no warning, UNEXPECTED
there is no warning, even thought the method is defined as - (BOOL)intersectsSet:(NSSet *)otherSet; so one would expect (1) and (2) to be equivalent. Mayhaps the vile compiling tool considers (1) to be of a more dangerous nature compared to (2), but why does that affect warnings, I ask?
So, how to make compiler produce the same warning in (2) as in (1)?
This behavior in the compiler seems intentional (and reasonable.)
If the -Wunused-value warning were emitted for all ObjC message send expressions where the method has a return value that is implicitly discarded (i.e. there is no void cast,) it would be so “chatty” that it would render itself useless. In other words, people would get such large numbers of warnings for existing projects that they would simply turn the warning off, rather than annotate all such cases with (void) casts.
The fact that the warning is emitted in the case where the return value is cast to BOOL is a nice surprise, and makes sense: it's reasonable for the compiler to then assume that the programmer is indeed interested in the return value (because why otherwise include the cast?)
The Clang development community on the cfe-dev mailing list might be able to give you more information on the thinking behind this.
I don't know of any way to force the behavior you want in general, but for the interfaces in your own code you can force this warning by using the warn_unused_result attribute in the ObjC method (or C function) declaration:
#interface MyClass : NSObject
- (int) myReturnValueMustNotBeIgnored __attribute__((warn_unused_result));
#end
Related
the Code: [NSClassFromString(#"Test") gotoTest];
usage ARC with Error: No known class method for selector 'gotoTest'
but in MRC warning no error.
Way ARC from warning becomes an error ? do you have any reference? I want to know the essential reason.
You did not include the warning under MRC:
Class method '+gotoTest' not found (return type defaults to 'id')
and this contains a vital clue – the compiler is looking for the return type. Under MRC it assumes id and will let you assign the result as an object reference. If you mess up and the return type is, say, float, things will probably go wrong.
Under ARC it is the compilers job to do the memory management of any returned value, and to do this correctly it needs to the the type. So if it can't determine the return type it produce an error.
Your code fragment suggests you know the selector takes no arguments and returns no value, so declare it as such. If you've no class with the method you can use a protocol, something like:
#protocol GotoTest
+ (void) gotoTest;
#end
will do. Now the compiler knows the types and your code will compile under ARC.
HTH
With code like this:
- (nonnull NSString *)testing {
return nil;
}
Shouldn't I get a compiler warning? I get no warning all, which seems to make the entire nullability stuff seem useless?
Well, in my opinion it should produce a warning, but I couldn't figure out to get one either.
What might be helpful though, is using Product > Analyze to run the CLANG Static Analyzer. This should give the following hint:
Null is returned from a method that is expected to return a non-null value
Another thing worth mentioning is the setting CLANG_WARN_NULLABLE_TO_NONNULL_CONVERSION which is named Incorrect Uses of Nullable values in the Apple LLVM 7.1 - Warnings - All languages section of the Build Settings.
This setting will not produce a warning for incorrect return values, but it shows a warning when using the method with incorrect parameters (e.g. nil for nonnull parameters).
This answer refers to Xcode Version 7.3.1 (7D1014)
"nonnull" is mostly there to combine Objective-C and Swift. Swift will translate the type of the method to "NSString" and not "NSString?".
In my implementation model, I need to have some differents files, with some similar methods. Also, I gather objects of differents types in a NSMutableArray, and try to call my similar method like this:
[[ArrayOfViews objectAtIndex:i] myMethodWithInt:'number' andExample:'char'];
But it gives me a warning:
Instance method '...' not found (return type defaults to 'id')
My code works, but should I fix this warning or not?
You should introduce the type:
MONType * obj = [ArrayOfViews objectAtIndex:i];
Then call the method using the typed variable:
[obj myMethodWithInt:<#number#> andExample:<#char#>];
It could be complaining for a number of reasons. Introducing the type will either fix those categories of issues, or at least give you a more useful warning. Specifically, the compiler does not see a declaration of the instance method -myMethodWithInt:andExample:.
You've likely either not imported a header, or declared the method so that it is visible in the translation.
My code works, but should I must fix this warning or not ?
Maybe. Sometimes it will 'work'. This is equivalent to C89's missing function prototypes, which were phased out because of all the issues they caused. So implicit parameters and return types can work if the parameters and return type is id compatible (including NSObject subclasses). But if it is not a match, then you should expect undefined behavior. You can avoid all this and introduce meaningful type checking by using the appropriate imports and declarations in your programs, and by introducing the type as illustrated above. This is useful because the compiler will save you from a ton of silly mistakes as you work and as your codebases evolve.
It's probably just a case of not having the method declared before the call. Try adding the method declaration to the interface section of the class.
Adding a typecast to your objectAtIndex call with get rid of the warning. This isn't a big issue, but it's good practice to typecast returns from an NSArray.
Basically:
YourObjectType *yourObject = (YourObjectType*)[ArrayOfViews objectAtIndex:i];
[yourObject myMethodWithInt:'number' andExample:'char'];
You need to add an #import statement for the header that declares the method or methods you want to call.
The Objective C Runtime Guide from Apple, states that you should never use objc_msgSend() in your own code, and recommends using methodForSelector: instead. However, it doesn't provide any reason for this.
What are the dangers of calling objc_msgSend() in your code?
Reason #1: Bad style - it's redundant and unreadable.
The compiler automatically generates calls to objc_msgSend() (or some variant thereof) when it encounters Objective-C messaging expressions. If you know the class and the selector to be sent at compile-time, there's no reason to write
id obj = objc_msgSend(objc_msgSend([NSObject class], #selector(alloc)), #selector(init));
instead of
id obj = [[NSObject alloc] init];
Even if you don't know the class or the selector (or even both), it's still safer (at least the compiler has a chance to warn you if you are doing something potentially nasty/wrong) to obtain a correctly typed function pointer to the implementation itself and use that function pointer instead:
const char *(*fptr)(NSString *, SEL) = [NSString instanceMethodForSelector:#selector(UTF8String)];
const char *cstr = fptr(#"Foo");
This is especially true when the types of the arguments of a method are sensitive to default promotions - if they are, then you don't want to pass them through the variadic arguments objc_msgSend() takes, because your program will quickly invoke undefined behavior.
Reason #2: dangerous and error-prone.
Notice the "or some variant thereof" part in #1. Not all message sends use the objc_msgSend() function itself. Due to complications and requirements in the ABI (in the calling convention of functions, in particular), there are separate functions for returning, for example, floating-point values or structures. For example, in the case of a method that performs some sort of searching (substrings, etc.), and it returns an NSRange structure, depending on the platform, it may be necessary to use the structure-returning version of the messenger function:
NSRange retval;
objc_msgSend_stret(&retval, #"FooBar", #selector(rangeOfString:), #"Bar");
And if you get this wrong (e. g. you use the inappropriate messenger function, you mix up the pointers to the return value and to self, etc.), your program will likely behave incorrectly and/or crash. (And you will most probably get it wrong, because it's not even that simple - not all methods returning a struct use this variant, since small structures will fit into one or two processor registers, eliminating the need for using the stack as the place of the return value. That's why - unless you are a hardcore ABI hacker - you rather want to let the compiler do its job, or there be dragons.)
You ask "what are the dangers?" and #H2CO3 has listed some ending with "unless you are a hardcore ABI hacker"...
As with many rules there are exceptions (and possibly a few more under ARC). So your reasoning for using msgSend should go something along the lines of:
[ 1] I think I should use msgSend - don't.
[2] But I've a case here... - you probably haven't, keep looking for another solution.
...
[10] I really think I should use it here - think again.
...
[100] Really, this looks like a case for msgSend, I can't see any other solution! OK, go read Document.m in the TextEdit code sample from Apple. Do you know why they used msgSend? Are you sure... think again...
...
[1000] I understand why Apple used it, and my case is similar... You've found and understood the exception that proves the rule and your case matches, use it!
HTH
I can make a case. We used msgSend in one of our C++ files (before we switched to ARC) that's in a cross-platform project (Windows, Mac and Linux). We use it to ref count a reference in the backed (the shared code) that's used later to go from frontend to backend and vice versa. Very special case, admittedly.
I am fairly new to Objective-C. Currently porting my own library from C#/Java to objective C.
I now run into a very strange problem for me.
I have a NSArray with several Note objects. I want to transpose on of these notes:
//Note.h
- (Note *) transpose: (int) semitones;
//Main
NSArray *notes = [get it from somewhere];
Note *transposedNote = [[notes objectAtIndex:0]transpose:1]; //Doesn't compile
Note *transposedNote = [(Note*)[notes objectAtIndex:0]transpose:1]//Does compile
Is this happening because there is already a transpose method available in the general libraries?
I thought due to the dynamic nature of objective-C at runtime it would be checked which class objectAtIndex returns and then sends the message to it?
It is my understanding that there is no runtime type checking for the assignment operator in Objective C. Since an array can contain a mixture of types, there is no way for the system to know what objectAtIndex returns.
How about
Note *transposedNote = [notes objectAtIndex:0]; // first line
[transposedNote transpose:1]; // second line
? Notice in the reference that objectAtIndex: returns an id, you will see it is pretty obvious:
In the code above, because id can fit into any object, the first line doesn't need to cast it into Note. In the second line I'm just calling a method on a Note so the compiler is happy.
In your code you are calling methods on the returned id object, so the compiler doesn't understand what you are trying to do. Just assign it to a Note reference and it will be fine.
Yes, the error is because there's already a transpose: method in AppKit. And you're also right that it normally doesn't cause an error when you have two unrelated classes implementing methods with the same name. The reason you get an error is because the two methods either return incompatible types or take incompatible types as arguments. In your particular case, you're seeing both problems:
-[NSResponder transpose:] takes an id and returns void
-[Note transpose:] takes an int and returns an id
These are totally incompatible types, and the compiler does need to know the types involved even if it doesn't know what exact method is going to be called.
It does compile unless you have -Werror set to treat warnings as errors.
It might produce a warning if the compiler doesn't already know about the selector or if the selector is declared in more than one class. In the former case, it should be necessary only to import the interface containing the selector. In the latter case, you'll need to do the cast to suppress the error.