Skip navigation.
 
mlRe: Dynamic message typing problem
FROM : Julius Guzy
DATE : Fri May 16 23:17:19 2008

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.

Michael Vannorsdel's reply to this post today at 17.30 states "I've 
tried the code here and it works as expected" which led him to 
suspect there was something wrong with the way I had Xcode configured.
I think I'll soon put up a post about what might be the standard 
build parameters on the Xcode mailing list.
However in similar tests involving NSString I got the correct result, 
Ahh.. but of course! the address of the string would be an integer! 
Right right.

Any idea where I should look to find ways of correcting this code?
Does one need to store the SEL or something like that?

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?

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......

Help!!!

P.S.
Does this problem of mine qualify as an example of the difficulties 
in learning cocoa recently discussed on this list?

Julius

http://juliuspaintings.co.uk

Related mailsAuthorDate
mlDynamic message typing problem Julius Guzy May 15, 03:19
mlRe: Dynamic message typing problem Michael Vannorsdel May 15, 13:41
mlRe: Dynamic message typing problem Julius Guzy May 16, 17:21
mlRe: Dynamic message typing problem Michael Vannorsdel May 16, 18:12
mlRe: Dynamic message typing problem Julius Guzy May 16, 19:13
mlRe: Dynamic message typing problem Scott Ribe May 16, 20:11
mlRe: Dynamic message typing problem Julius Guzy May 16, 23:17
mlRe: Dynamic message typing problem Bill Bumgarner May 16, 23:34
mlRe: Dynamic message typing problem Scott Ribe May 16, 23:52
mlRe: Dynamic message typing problem Michael Vannorsdel May 17, 00:06
mlRe: Dynamic message typing problem Scott Ribe May 17, 00:39
mlRe: Dynamic message typing problem I. Savant May 17, 01:05
mlRe: Dynamic message typing problem Julius Guzy May 17, 01:51
mlRe: Dynamic message typing problem Bill Bumgarner May 17, 01:58
mlRe: Dynamic message typing problem Jens Alfke May 17, 02:11
mlRe: Dynamic message typing problem I. Savant May 17, 02:21
mlRe: Dynamic message typing problem Julius Guzy May 17, 13:55
mlRe: Dynamic message typing problem Michael Vannorsdel May 17, 15:40