Cocoa mail archive
Re: Dynamic message typing problem
FROM : Bill Bumgarner
DATE : Fri May 16 23:34:33 2008
On May 16, 2008, at 2:17 PM, Julius Guzy wrote:
> On 16 May 2008, at 19:23 Scott Ribe <<email_removed>> wrote
>>>
>>> - (void) callPrintConstFloat:(id)pId {
>>> [pId printFloat:98.76]; // pId is object of
>>> class AnonTargetClass
>>> }
>>
>> This is probably compiled in file which does not include the
>> declaration of
>> class AnonTargetClass, so the compiler assumes that printFloat
>> takes an int,
>> casts 98.76 to the int 98, and passes those 4 bytes to a method
>> that's
>> expecting a float or double. You should be seeing a compiler
>> warning about
>> this.
> Thanks Scott.
>
> Yes, the file did not include declaration of AnonTargetClass.
> I did see compiler warnings but I've always seen these on the G4 and
> the system worked perfectly well.
An almost universal rule of Mac OS X programming: If you see a
compiler warning, you are doing something wrong.
Fix the compiler warnings first (and correctly -- i.e. casting willy-
nilly is not a fix) and then address the real problems within your
code that remain.
In this case, that the code worked on any platform is merely a
coincidence brought about by the architecture of said platform and the
compiler.
> Any idea where I should look to find ways of correcting this code?
> Does one need to store the SEL or something like that?
You need to declare -printFloat: someplace that the compilation of the
above will see the declaration and will interpret the arguments
correctly.
This may be as simple as #import'ing an appropriate header file. A
more precise fix would be to not use (id) as the parameter type, but
to declare the type explicitly. This would have the side effect of
requiring that you #import the class definition (or use @class, which
won't solve the problem).
> Also do you have any idea of where I could look for a description,
> (possibly with an example ?) of the standard approach to dynamic
> typing when it is not possible to include the header of the called
> object, for instance when having to avoid circularity in header file
> definition or the object is being defined on the fly?
Circularity of includes is easily addressed by using @class in the
header portion to forward declare classes such that the circularity is
avoided.
As per the implementation, circularity of includes should not be any
more of an issue than in headers. It is simply a matter of including
the files in the right order.
Which, of course, is a pain in the butt and for which Xcode projects
offer project headers and precompiled headers such that you can have
one master (or set of masters) header(s) that are included in your
implementation files instead of mentioning individual header files.
> Even so I'm puzzled.
> I thought cocoa was designed to allow dynamic typing i.e. where the
> class of the called object is not declared in the calling file and
> that the run time resolution process involves searching a method
> table for a match of the method call and by this means, if the
> method name is unique, the types of the parameters are determined.
> Indeed is this not just the standard messaging mechanism? Or is this
> why I sometimes have the impression that cocoa encourages us to pass
> Objects as parameters to everything? The Kochan "Programming in
> Objective-C" does note the possibility of conflict when method names
> are not unique but here the method is unique. and exactly, even if
> we are passing object ids these will eventually need to be resolved
> so that brings us back to square one......
The runtime resolution process is very good about figuring out what
method to call dynamically at runtime, but Objective-C is still a C
derived language. Thus, it benefits from all of the efficiencies and
suffers from all of the idiosyncrasies of C.
In this case, you haven't given the compiler enough information about
the size and encoding of the parameters. By the time the runtime
sees the method call, the compiler has already had its way with the
arguments -- potentially promoting the float to an int or otherwise
losing information.
You need to make the method declaration visible to the compiler to
make this work.
> P.S.
> Does this problem of mine qualify as an example of the difficulties
> in learning cocoa recently discussed on this list?
Not really. Ignoring compiler warnings is a common mistake that many
many folk make when first learning C, Objective-C or C++, regardless
of targeted programming environment.
The tools are trying to help you by pointing out where you have done
something that is incompletely specified. Fix the warning, most of
your problems are likely to go away.
b.bum
DATE : Fri May 16 23:34:33 2008
On May 16, 2008, at 2:17 PM, Julius Guzy wrote:
> On 16 May 2008, at 19:23 Scott Ribe <<email_removed>> wrote
>>>
>>> - (void) callPrintConstFloat:(id)pId {
>>> [pId printFloat:98.76]; // pId is object of
>>> class AnonTargetClass
>>> }
>>
>> This is probably compiled in file which does not include the
>> declaration of
>> class AnonTargetClass, so the compiler assumes that printFloat
>> takes an int,
>> casts 98.76 to the int 98, and passes those 4 bytes to a method
>> that's
>> expecting a float or double. You should be seeing a compiler
>> warning about
>> this.
> Thanks Scott.
>
> Yes, the file did not include declaration of AnonTargetClass.
> I did see compiler warnings but I've always seen these on the G4 and
> the system worked perfectly well.
An almost universal rule of Mac OS X programming: If you see a
compiler warning, you are doing something wrong.
Fix the compiler warnings first (and correctly -- i.e. casting willy-
nilly is not a fix) and then address the real problems within your
code that remain.
In this case, that the code worked on any platform is merely a
coincidence brought about by the architecture of said platform and the
compiler.
> Any idea where I should look to find ways of correcting this code?
> Does one need to store the SEL or something like that?
You need to declare -printFloat: someplace that the compilation of the
above will see the declaration and will interpret the arguments
correctly.
This may be as simple as #import'ing an appropriate header file. A
more precise fix would be to not use (id) as the parameter type, but
to declare the type explicitly. This would have the side effect of
requiring that you #import the class definition (or use @class, which
won't solve the problem).
> Also do you have any idea of where I could look for a description,
> (possibly with an example ?) of the standard approach to dynamic
> typing when it is not possible to include the header of the called
> object, for instance when having to avoid circularity in header file
> definition or the object is being defined on the fly?
Circularity of includes is easily addressed by using @class in the
header portion to forward declare classes such that the circularity is
avoided.
As per the implementation, circularity of includes should not be any
more of an issue than in headers. It is simply a matter of including
the files in the right order.
Which, of course, is a pain in the butt and for which Xcode projects
offer project headers and precompiled headers such that you can have
one master (or set of masters) header(s) that are included in your
implementation files instead of mentioning individual header files.
> Even so I'm puzzled.
> I thought cocoa was designed to allow dynamic typing i.e. where the
> class of the called object is not declared in the calling file and
> that the run time resolution process involves searching a method
> table for a match of the method call and by this means, if the
> method name is unique, the types of the parameters are determined.
> Indeed is this not just the standard messaging mechanism? Or is this
> why I sometimes have the impression that cocoa encourages us to pass
> Objects as parameters to everything? The Kochan "Programming in
> Objective-C" does note the possibility of conflict when method names
> are not unique but here the method is unique. and exactly, even if
> we are passing object ids these will eventually need to be resolved
> so that brings us back to square one......
The runtime resolution process is very good about figuring out what
method to call dynamically at runtime, but Objective-C is still a C
derived language. Thus, it benefits from all of the efficiencies and
suffers from all of the idiosyncrasies of C.
In this case, you haven't given the compiler enough information about
the size and encoding of the parameters. By the time the runtime
sees the method call, the compiler has already had its way with the
arguments -- potentially promoting the float to an int or otherwise
losing information.
You need to make the method declaration visible to the compiler to
make this work.
> P.S.
> Does this problem of mine qualify as an example of the difficulties
> in learning cocoa recently discussed on this list?
Not really. Ignoring compiler warnings is a common mistake that many
many folk make when first learning C, Objective-C or C++, regardless
of targeted programming environment.
The tools are trying to help you by pointing out where you have done
something that is incompletely specified. Fix the warning, most of
your problems are likely to go away.
b.bum
