Re: Dynamic message typing problem
Re: Dynamic message typing problem
- Subject: Re: Dynamic message typing problem
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 16 May 2008 14:34:33 -0700
On May 16, 2008, at 2:17 PM, Julius Guzy wrote:
On 16 May 2008, at 19:23 Scott Ribe <email@hidden> 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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden