Re: Dynamic message typing problem
Re: Dynamic message typing problem
- Subject: Re: Dynamic message typing problem
- From: Michael Vannorsdel <email@hidden>
- Date: Fri, 16 May 2008 16:06:40 -0600
Just to add, it's generally important to include compiler warnings
with your problem description as they provide valuable clues. The
compiler issues warnings when something doesn't look right, make
sense, or lacking information. Usually the compiler will make guesses
and assumptions as to what you want the code to do, which is not
always correct. The binary will build but may not function as intended.
On May 16, 2008, at 3:34 PM, Bill Bumgarner wrote:
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.
_______________________________________________
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