Re: How to avoid warning with objc_msgSend

FROM : David Elliott
DATE : Tue Oct 05 20:28:54 2004

Hi,

Chiming in here as the author of this code.

You can find it at wxWidgets ViewCVS.  The relevant change (and 
relevant code) is here:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/cocoa/
window.mm.diff?r1=1.44&r2=1.45

The latest complete copy is here:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/cocoa/window.mm?
rev=1.48&content-type=text/vnd.viewcvs-markup

On Oct 5, 2004, at 12:15 PM, Finlay Dobbie wrote:

> On 5 Oct 2004, at 09:46, Ryan Norton wrote:
>

>>> Anyhow, assuming that GetNSView() is a function returning a pointer 
>>> to an NSViewInstance, why don't you just send it normally?
>>>
>>> id aView = GetNSView();
>>> NSRect *rects;
>>> int rectCount;
>>> [aView getRectsBeingDrawn:&rects count:&rectCount];

>>
>> Because this generates both a runtime and compiler warning on 10.2 
>> and lower (using the id instead of a plain GetNSView generates an 
>> extra compiler warning also) :).

>


This is what I have now
--- code ---
    // Set m_updateRegion
    const NSRect *rects = ▭ // The bounding box of the region
    int countRects = 1;
    // Try replacing the larger rectangle with a list of smaller ones:
NS_DURING
    // This only works on Panther
//    [GetNSView() getRectsBeingDrawn:&rects count:&countRects];
    // This compiles everywhere (and still only works on Panther)
     
objc_msgSend(GetNSView(),@selector(getRectsBeingDrawn:
count:),&rects,&countRects);
NS_HANDLER
NS_ENDHANDLER
--- code ---

> Then do this:
>
> id aView = GetNSView();
> NSRect *rects = NULL;
> int rectCount = 0;
> if ([aView respondsToSelctor:@selector(getRectsBeingDrawn:count:)]) {
>     [aView getRectsBeingDrawn:&rects count:&rectCount];
> }
>
> That obviously won't cause a runtime warning on 10.2 and lower. It'll 
> cause a compile-time warning, removing that would be an exercise for 
> the reader (hint: define a protocol, but this is really bad practice 
> as those methods aren't really implemented and thus the warning is 
> perfectly valid).
>

Right.  I could have used a protocol but I didn't see the point when I 
could just as easily call objc_msgSend myself and get (AFAICT) the 
exact same result.

The problem I have is not that the compiler issues a warning (it 
doesn't, obviously) but that the runtime on 10.2 issues a warning.  I 
would have thought that the whole point of catching the exception is to 
avoid any ill effects that may happen from calling an unimplemented 
method.  And indeed, without catching the exception the app will crash. 
  But even when I do catch it it emits a console warning which IMHO is 
ridiculous.

I had thought about using respondsToSelector though it seemed there 
ought to be a way to have it attempt to call the method and in the 
event that it is not implemented simply ignore the error rather than 
checking if it is implemented each time before calling the method.

If there is no way to silence the runtime warning I have two choices:
1) use the above method and see if it's implemented before calling it
2) just remove the code since most apps probably won't benefit from 
this optimization anyway.

-Dave