macOS Strange warnings

[netytan]

Hey all,

Things are going pretty well on my little project, but I have noticed a several little warnings that it doesn't seem I can fix unless I for instance overriding alloc to do nothing.

.../CSMainDocument.m:39: warning: `CSMainWindowController' may not respond to `+alloc'
.../CSMainDocument.m:39: warning: (Messages without a matching method signature
.../CSMainDocument.m:39: warning: will be assumed to return `id' and accept
.../CSMainDocument.m:39: warning: `...' as arguments.)
.../CSMainDocument.m:42: warning: passing argument 1 of 'addWindowController:' from incompatible pointer type

All of these are related to alloc not explicitly being defined in my subclass of NSWindowController, now I don't see the point in implementing alloc and doing nothing with it.

Is it ok to just ignore the warnings, or is there a better way that I can fix them?

I'm loathed to leave them there but I also don't want add code bloat for no reason. It seems that Xcode is a little picky about this kind of thing, it also doesn't handle code completion for subclasses very well .

Thanks for any advice,

Mark.

 

[robbieduncan]

What type is CSMainWindowController? Have you imported it's header or just declared it's existence via a @class directive? If you have imported it's header are you sure you've declared it's superclass? If you haven't imported it's header and are using @class is there a reason you can't import the header?

 

[caveman_uk]

IIRC alloc is defined in NSObject which all other classes are decended from. You shouldn't need to define alloc as it's inherited. Sounds like something's wrong somewhere with the way you're doing things...

Generally warnings are there for a reason.

 

[zimv20]

time to post some code...

 

[robbieduncan]

IIRC alloc is defined in NSObject which all other classes are decended from. You shouldn't need to define alloc as it's inherited. Sounds like something's wrong somewhere with the way you're doing things...

Generally warnings are there for a reason.

This is all true but I've noticed in recent XCode versions that if you define a variable as say

id myClassInstance

and then try and call a method that is in NSObject on it then you get warnings. I think this is because id is defined as void * and the compiler cannot be sure that it's even an NSObject. A way round this is to define it as

id<NSObject> myClassInstance

 

[caveman_uk]

This is all true but I've noticed in recent XCode versions that if you define a variable as say

id myClassInstance

and then try and call a method that is in NSObject on it then you get warnings. I think this is because id is defined as void * and the compiler cannot be sure that it's even an NSObject. A way round this is to define it as

id<NSObject> myClassInstance

Ah, I rarely define anything as id so I might not have seen it. Obviously sometimes you need to define things as id - I just tend to avoid it.

 

[robbieduncan]

Ah, I rarely define anything as id so I might not have seen it. Obviously sometimes you need to define things as id - I just tend to avoid it.

I generally only use id for delegates. It's getting a bit annoying as I used to just do:

id<MyDelegateProtocol> delegate;

but now I'm needing

id<NSObject,MyDelegateProtocol> delegate;

It's not all that much extra work really but I'm sure the first one used to work with no warnings!

 

[netytan]

...It's not all that much extra work really but I'm sure the first one used to work with no warnings!

Likewise, when I first used Cocoa about a year ago I never get any errors like this then I went away to work with other things and no warnings . In any case I was using @class because I read that it reduced compile times. I included the header and the warnings went away so I'm happy now .

Thanks a lot guys,

Mark.