FROM : Graham Cox
DATE : Sun Jun 08 14:41:39 2008
These sounded just the ticket... but unfortunately they generate
literally thousands of unwarranted warnings, so again, if they do pick
up genuine transgressions it is way below the noise floor.
Almost every call to a Cocoa instance method (or one private to my
code for that matter) generates a warning. I don't really understand
why, since the code looks fine to me (2 examples from 10,000 listed
warnings!):
if([str isEqualToString:@"GC"]){...}
warning: creating selector for nonexistent method 'isEqualToString:'
BOOL newFileFormat = [coder decodeBoolForKey:@"hasHierarchicalLayers"];
warning: creating selector for nonexistent method 'decodeBoolForKey:'
and so on, and so on...
warning: creating selector for nonexistent method 'decodeBoolForKey:'
warning: creating selector for nonexistent method 'decodeSizeForKey:'
warning: creating selector for nonexistent method 'decodeIntForKey:'
warning: creating selector for nonexistent method 'encodeBool:forKey:'
warning: creating selector for nonexistent method 'encodeSize:forKey:'
warning: creating selector for nonexistent method 'encodeInt:forKey:'
and 10,000 others.
On 7 Jun 2008, at 1:41 am, j o a r wrote:
> You might want to experiment with enabling one or more of the
> following optional warnings:
>
> -Wselector
> Warn if multiple methods of different types for the same selector
> are found during compilation. The check is performed on the list of
> methods in the final stage of compilation. Additionally, a check is
> performed for each selector appearing in a "@selector(...)"
> expression, and a corresponding method for that selector has been
> found during compilation. Because these checks scan the method table
> only at the end of compilation, these warnings are not produced if
> the final stage of compilation is not reached, for example because
> an error is found during compilation, or because the -fsyntax-only
> option is being used.
> -Wstrict-selector-match
> Warn if multiple methods with differing argument and/or return types
> are found for a given selector when attempting to send a message
> using this selector to a receiver of type "id" or "Class". When this
> flag is off (which is the default behavior), the compiler will omit
> such warnings if any differences found are confined to types which
> share the same size and alignment.
> -Wundeclared-selector
> Warn if a "@selector(...)" expression referring to an undeclared
> selector is found. A selector is considered undeclared if no method
> with that name has been declared before the "@selector(...)"
> expression, either explicitly in an @interface or @protocol
> declaration, or implicitly in an @implementation section. This
> option always performs its checks as soon as a "@selector(...)"
> expression is found, while -Wselector only performs its checks in
> the final stage of compilation. This also enforces the coding style
> convention that methods and selectors must be declared before being
> used.
>
> j o a r
>
>
DATE : Sun Jun 08 14:41:39 2008
These sounded just the ticket... but unfortunately they generate
literally thousands of unwarranted warnings, so again, if they do pick
up genuine transgressions it is way below the noise floor.
Almost every call to a Cocoa instance method (or one private to my
code for that matter) generates a warning. I don't really understand
why, since the code looks fine to me (2 examples from 10,000 listed
warnings!):
if([str isEqualToString:@"GC"]){...}
warning: creating selector for nonexistent method 'isEqualToString:'
BOOL newFileFormat = [coder decodeBoolForKey:@"hasHierarchicalLayers"];
warning: creating selector for nonexistent method 'decodeBoolForKey:'
and so on, and so on...
warning: creating selector for nonexistent method 'decodeBoolForKey:'
warning: creating selector for nonexistent method 'decodeSizeForKey:'
warning: creating selector for nonexistent method 'decodeIntForKey:'
warning: creating selector for nonexistent method 'encodeBool:forKey:'
warning: creating selector for nonexistent method 'encodeSize:forKey:'
warning: creating selector for nonexistent method 'encodeInt:forKey:'
and 10,000 others.
On 7 Jun 2008, at 1:41 am, j o a r wrote:
> You might want to experiment with enabling one or more of the
> following optional warnings:
>
> -Wselector
> Warn if multiple methods of different types for the same selector
> are found during compilation. The check is performed on the list of
> methods in the final stage of compilation. Additionally, a check is
> performed for each selector appearing in a "@selector(...)"
> expression, and a corresponding method for that selector has been
> found during compilation. Because these checks scan the method table
> only at the end of compilation, these warnings are not produced if
> the final stage of compilation is not reached, for example because
> an error is found during compilation, or because the -fsyntax-only
> option is being used.
> -Wstrict-selector-match
> Warn if multiple methods with differing argument and/or return types
> are found for a given selector when attempting to send a message
> using this selector to a receiver of type "id" or "Class". When this
> flag is off (which is the default behavior), the compiler will omit
> such warnings if any differences found are confined to types which
> share the same size and alignment.
> -Wundeclared-selector
> Warn if a "@selector(...)" expression referring to an undeclared
> selector is found. A selector is considered undeclared if no method
> with that name has been declared before the "@selector(...)"
> expression, either explicitly in an @interface or @protocol
> declaration, or implicitly in an @implementation section. This
> option always performs its checks as soon as a "@selector(...)"
> expression is found, while -Wselector only performs its checks in
> the final stage of compilation. This also enforces the coding style
> convention that methods and selectors must be declared before being
> used.
>
> j o a r
>
>






Cocoa mail archive

