Re: Dynamic message typing problem
This block is probably causing some corruption. You're assigning 123 to a uchar pointer and not the uchar, then passing the address of a pointer to a method that tries to printout the pointer as an int rather than the intended uchar value. On May 14, 2008, at 7:19 PM, Julius Guzy wrote: - (void) callPrintConstUnsignedCharRef:(id)pId; { unsigned char * tvarUnsignedChar= 123; [pId printUnsignedCharRef:&tvarUnsignedChar]; } ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
On 15 May 2008, at 14:40, [EMAIL PROTECTED] wrote: From: Michael Vannorsdel <[EMAIL PROTECTED]> Subject: Re: Dynamic message typing problem This block is probably causing some corruption. You're assigning 123 to a uchar pointer and not the uchar, then passing the address of a pointer to a method that tries to printout the pointer as an int rather than the intended uchar value. On May 14, 2008, at 7:19 PM, Julius Guzy wrote: - (void) callPrintConstUnsignedCharRef:(id)pId; { unsigned char * tvarUnsignedChar= 123; [pId printUnsignedCharRef:&tvarUnsignedChar]; } Yes thanks. That was careless of me. And I had made the problem statement far too long for the actual problem to stand out. It was that this: - (void) callPrintConstFloat:(id)pId { [pId printFloat:98.76]; // pId is object of class AnonTargetClass } causes this method in object of class AnonTargetClass - (void) printFloat:(float)pF { NSLog(@" %6.3f",pF); } to print -151996493463552.000 even though AnonTargetClass *atcObj = [[AnonTargetClass alloc] init]; [atcObj printFloat:98.76]; prints 98.760 Here's the full mainline and results #import #import "AnonTargetClass.h" #import "CallingClass.h" int main(int argc, char *argv[]) { AnonTargetClass * atcObj = [[AnonTargetClass alloc]init]; CallingClass* callingObj = [[CallingClass alloc]init]; [callingObj callPrintConstFloat:atcObj]; [atcObj printFloat:98.76]; } 2008-05-16 16:07:41.058 testDynamicBinding[856:10b] -151996493463552.000 2008-05-16 16:07:41.059 testDynamicBinding[856:10b] 98.760 Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
I've tried the code here and it works as expected. Could you give more detail on your build setup? Like what arch you're building for, how you're executing the program, if you're executing code other than this, if this is actually running as a plugin or loaded bundle. On May 16, 2008, at 9:21 AM, Julius Guzy wrote: Yes thanks. That was careless of me. And I had made the problem statement far too long for the actual problem to stand out. It was that this: - (void) callPrintConstFloat:(id)pId { [pId printFloat:98.76]; // pId is object of class AnonTargetClass } causes this method in object of class AnonTargetClass - (void) printFloat:(float)pF { NSLog(@" %6.3f",pF); } to print -151996493463552.000 even though AnonTargetClass *atcObj = [[AnonTargetClass alloc] init]; [atcObj printFloat:98.76]; prints 98.760 Here's the full mainline and results #import #import "AnonTargetClass.h" #import "CallingClass.h" int main(int argc, char *argv[]) { AnonTargetClass * atcObj = [[AnonTargetClass alloc]init]; CallingClass* callingObj = [[CallingClass alloc]init]; [callingObj callPrintConstFloat:atcObj]; [atcObj printFloat:98.76]; } 2008-05-16 16:07:41.058 testDynamicBinding[856:10b] -151996493463552.000 2008-05-16 16:07:41.059 testDynamicBinding[856:10b] 98.760 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
On Fri, 16 May 2008 10:12:24 -0600 Michael Vannorsdel wrote I've tried the code here and it works as expected. Could you give more detail on your build setup? Like what arch you're building for, This is running as stand alone app. on Mac Pro 10.5.2 how you're executing the program, From Xcode - build and run if you're executing code other than this, if this is actually running as a plugin or loaded bundle. No, nothing like that With regard to the build settings i'm not sure which items of information are significant. I left everything as default except that once the errors started to appear (in the code i ported from my G4) I made garbage collection required and the code to be developed for OS 10.5. Here are the settings that I'm guessing to be relevant: In the xcode project info window General Project Format: XCode 3.0 compatible Cross develop using Target SDK: Mac OS 10.5 Under Build> Configuration : Active Configuration Show Settings defined at this level Architectures ARCHS = ppc i386 Build Locations SDKROOT = $(DEVELOPER_SDK_DIR)/MacOSX10.5.sdk Linking PREBINDING = NO GCC 4.0 - Code Generation GCC_MODEL_TUNING = G5 (PowerPC G5 [-mtune=G5] GCC_ENABLE_OBJC_GC = required (Garbage collection = required) GCC - 4.0 Language GCC_INPUT_FILETYPE = sourcecode.c.objc(Objective-C) GCC - 4.0 Warnings GCC_WARN_ALLOW_INCOMPLETE_PROTOCOL = YES GCC_WARN_ABOUT_RETURN_TYPE = YES GCC_WARN_UNUSED_VARIABLE = YES Under Configurations Debug Release Is this information sufficient? Thanks Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
> - (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. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
On 16 May 2008, at 19:23 Scott Ribe <[EMAIL PROTECTED]> 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 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
On May 16, 2008, at 2:17 PM, Julius Guzy wrote: On 16 May 2008, at 19:23 Scott Ribe <[EMAIL PROTECTED]> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/coco
Re: Dynamic message typing problem
> ...if the method > name is unique, the types of the parameters are determined. Not unless a declaration is visible. Your reasoning is that there's no other printFloat: so the compiler should know, but this is still (sort of) C--if you don't include a declaration that tells the compiler what the parameter types are, it doesn't know. In other words, it ain't C# or Java, it depends on those .h files ;-) > Any idea where I should look to find ways of correcting this code? You need to have a declaration of printFloat visible where it is called. Any declaration of printFloat, not necessarily the one in the anonymous class: that one, or one in a base class, or a category, or a protocol. Also, you need to make sure that all instances of the printFloat: method are declared the same. OK, that is not ***100% strictly required***, but having a printFloat: in one class that takes a float, and one in another class that takes a different kind of argument, is ***not*** an easy thing to deal with. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
> Just to add, it's generally important to include compiler warnings > with your problem description... Yo, any list moms listening? This is a really good suggestion that seems like something that should perhaps be incorporated into monthly email summarizing the list & how to ask questions. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
Yo, any list moms listening? This is a really good suggestion that seems like something that should perhaps be incorporated into monthly email summarizing the list & how to ask questions. Yeah, it's been awhile since Scott Anguish's monthly mailing, hasn't it? Lots of traffic recently that kind of walks all over etiquette ... -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
Thanks to all who replied to my pleas for help. I took Bill and Scott's suggestions to heart and produced the answer I needed: Dynamic Typing which allows me to avoid circularity etc. I post the complete solution as an example and to check that I'm not running close to the wind by using a dummy class definition. The code gets no compiler warnings. // AnonTargetClass.h #import @interface AnonTargetClass : NSObject { } - (void) printFloat:(float)pF; // AnonTargetClass.m #import "AnonTargetClass.h" @implementation AnonTargetClass - (void) printFloat:(float)pF { NSLog(@"%7.3f",pF); } // DummyClass.h #import @interface DummyClass : NSObject { } - (void) printFloat:(float)pF; // DummyClass.m #import "DummyClass.h" @implementation DummyClass - (void) printFloat:(float)pF { } // CallingClass.h #import #import "DummyClass.h"; @interface CallingClass : NSObject { } - (void) callPrintConstFloat:(id)pId; - (void) callPrint:(id)pId zFloat:(float)pF; // CallingClass.m #import "CallingClass.h" @implementation CallingClass - (void) callPrintConstFloat:(id)pId { [pId printFloat:99.99]; } - (void) callPrint:(id)pId zFloat:(float)pF { [pId printFloat:pF]; } // main.m #import #import "AnonTargetClass.h" #import "CallingClass.h" int main(int argc, char *argv[]) { AnonTargetClass * atcObj= [[AnonTargetClass alloc]init]; CallingClass* callingObj= [[CallingClass alloc]init]; [callingObj callPrintConstFloat:atcObj]; [atcObj printFloat:88.88]; } [Session started at 2008-05-17 00:33:01 +0100.] 2008-05-17 00:33:01.988 testDynamicBinding[2436:10b] 99.990 2008-05-17 00:33:01.989 testDynamicBinding[2436:10b] 88.880 Thanks again Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
On May 16, 2008, at 4:51 PM, Julius Guzy wrote: Thanks to all who replied to my pleas for help. I took Bill and Scott's suggestions to heart and produced the answer I needed: Dynamic Typing which allows me to avoid circularity etc. Good. BTW: Nice paintings. I post the complete solution as an example and to check that I'm not running close to the wind by using a dummy class definition. The code gets no compiler warnings. You don't need the dummy class. I'd do it something like this (Mail Code -- this probably won't compile). Only I'd also pull out all of the #imports and move to using a shared precomp for the project... // AnonTargetClass.h #import @interface AnonTargetClass : NSObject { } - (void) printFloat:(float)pF; // AnonTargetClass.m #import "AnonTargetClass.h" @implementation AnonTargetClass - (void) printFloat:(float)pF { NSLog(@"%7.3f",pF); } // CallingClass.h #import @class AnonTargetClass; @interface CallingClass : NSObject { } - (void) callPrintConstFloat:(AnonTargetClass *)pId; - (void) callPrint:(id)pId zFloat:(float)pF; // CallingClass.m #import "CallingClass.h" #import "AnonTargetClass.h" @implementation CallingClass - (void) callPrintConstFloat:(AnonTargetClass *)pId { [pId printFloat:99.99]; } - (void) callPrint:(id)pId zFloat:(float)pF { [pId printFloat:pF]; } // main.m #import #import "AnonTargetClass.h" #import "CallingClass.h" int main(int argc, char *argv[]) { AnonTargetClass * atcObj= [[AnonTargetClass alloc]init]; CallingClass* callingObj= [[CallingClass alloc]init]; [callingObj callPrintConstFloat:atcObj]; [atcObj printFloat:88.88]; } ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
On 16 May '08, at 2:34 PM, Bill Bumgarner wrote: An almost universal rule of Mac OS X programming: If you see a compiler warning, you are doing something wrong. Amen. One of the first things I do to any Xcode project I work on is turn on "Treat warnings as errors" in the build settings. For some reason almost all of Obj-C's type-checking errors appear as warnings, and you ignore those at your peril. (I also recommend adding "-Wall" to the "Other warning flags" field. That enables [almost] all warnings. Yes, you'll sometimes have to tweak correct code that triggers a warning; but that's much less time consuming than tracking down a bizarre runtime problem that could have been detected by the compiler if you'd let it.) —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
Amen. One of the first things I do to any Xcode project I work on is turn on "Treat warnings as errors" in the build settings. For some reason almost all of Obj-C's type-checking errors appear as warnings, and you ignore those at your peril. VERY good advice. A little self-discipline is good. I admit to previously being very bad about "harmless" warnings. By harmless, I mean the "may not respond to" variety. It's messy, though, and it always rubbed my OCD wrong. ;-) Hi. I'm Idiot Savant and I have a Warnings problem. I've been clean for about a year now and it gets easier every day ... < sits down, waits for clapping > -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
On 17 May 2008, at 0:58, Bill Bumgarner wrote: BTW: Nice paintings. Thanks I post the complete solution as an example and to check that I'm not running close to the wind by using a dummy class definition. The code gets no compiler warnings. You don't need the dummy class. I'd do it something like this (Mail Code -- this probably won't compile). Only I'd also pull out all of the #imports and move to using a shared precomp for the project... I'm not sure I fully understand the ideas in the example code but have started looking up the documentation re precompiled headers so hopefully I'll get a handle on it by end of day. My problem is that I am desperate to get up and running a number of prototype examples of what my program is intended to do (e.g. see http://animatedpaint.co.uk/nesta) as quickly as i possibly can and the world is conspiring against me: in a weeks time i'll have to be away from the computer for a month or so. I have a couple of key bits of logic to implement after which I can better decide the developmental path to take. So I'm trying to keep the system side as simple as I can conceivably make it whilst always keeping an eye to the future. I really like the idea of nibs and keeping things independent from each other because i hate complexity and will go to ends of the earth to avoid it. So i love messaging and the idea of dynamic typing as a means of communicating between independent subsystems. Why am I saying all of this... months of struggle and then after making a major investment in a mac pro with 4 x 500GB raid etc etc (and that not working properly either) and having some key communications code fail on me... . I'll get it all sorted when i get back. By the way, thanks to you all who have been emphasising the need to really take notice of the compiler warnings. I do do this normally - really I do. I hate having warnings anywhere near me!!!. In the case of Dynamic Typing I just thought this happened to be one of those hits to cleanliness one had to take. So very happilly I stand corrected. And Jens yes, I will switch on the extra warnings flags, thanks. I would like to ask you all this one extra question to further my understanding. According to the Defining a Class section of the The Objective-C 2.0 Programming Language documentation, the ability to identify the identity of an object at runtime is given by the sequence: id -> isa - > class description vis: < quote> The id type is completely nonrestrictive. By itself, it yields no information about an object, except that it is an object. Since the id type designator can’t supply [the object's methods, variables] to the compiler, each object has to be able to supply it at runtime. every object carries with it an isa instance variable that identifies the object’s class—what kind of object it is. Objects are thus dynamically typed at runtime. Whenever it needs to, the runtime system can find the exact class that an object belongs to, just by asking the object. Dynamic typing in Objective-C serves as the foundation for dynamic binding, discussed later. Assume a file which contains a call of the form int tempVar = [idValue methodIdentifier:param]; Assume there is no header file to give information about methodIdentifier and its parameters. The problem for the compiler is to determine the return type and the type of the parameter "param". We have already established that (one way) this problem can be resolved is if the calling file includes the header of a dummy class which includes a method called "methodIdentifier:" of type say float and that returns an integer say. Could not the compiler have been given the exact same information through coercion viz: int tempVar = (int)[idValue methodIdentifier:(float)param]; This does not work but what is wrong with this line of reasoning and/ or why could the system not make use of coercion as part of a dynamic typing mechanism? Thanks again Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamic message typing problem
The difficulty is methods in ObjC are dispatched messages rather than hardcoded functions so going from call to method execution has some hidden intermediate steps. And there can be more than one method with the same name from different classes/protocols. This is one of the pillars to ObjC's runtime flexibility as it allows methods to be added and checked during runtime. Further complicating the matter is the differences in how PPC and 32 bit Intel pass arguments (why your previous code may have worked on PPC and not Intel; PPC passes args via registers, Intel 32 via the stack). Not to mention any future differences of new archs. Lets say for instance you had the method: - (NSString*)doSomethingWith:(int)val; and you used it like: [obj doSomethingWith:(float)val]; The compiler knows the argument is supposed to be an int so it will cast val to a float and then to an int before passing it on to the method. Casting the arg doesn't change the method's accepted arg type. When the types are unknown the compiler has to assume the types (like id for return values) and will cast args to those assumed types, which may not be compatible for the actual type. For instance, if the compiler assumed int for the arg type, stores val as an int on the stack (Intel 32), and the actual method expects a float, it will load the stack value believing it's a float type and end up with a weird value. Int 5 and float 5.0 are totally different at the binary level. On PPC the method would probably use the wrong register. The method declaration is how the compiler knows what form to write the var to the stack as or which register to put it in. On May 17, 2008, at 5:55 AM, Julius Guzy wrote: The id type is completely nonrestrictive. By itself, it yields no information about an object, except that it is an object. Since the id type designator can’t supply [the object's methods, variables] to the compiler, each object has to be able to supply it at runtime. every object carries with it an isa instance variable that identifies the object’s class—what kind of object it is. Objects are thus dynamically typed at runtime. Whenever it needs to, the runtime system can find the exact class that an object belongs to, just by asking the object. Dynamic typing in Objective-C serves as the foundation for dynamic binding, discussed later. Assume a file which contains a call of the form int tempVar = [idValue methodIdentifier:param]; Assume there is no header file to give information about methodIdentifier and its parameters. The problem for the compiler is to determine the return type and the type of the parameter "param". We have already established that (one way) this problem can be resolved is if the calling file includes the header of a dummy class which includes a method called "methodIdentifier:" of type say float and that returns an integer say. Could not the compiler have been given the exact same information through coercion viz: int tempVar = (int)[idValue methodIdentifier:(float)param]; This does not work but what is wrong with this line of reasoning and/ or why could the system not make use of coercion as part of a dynamic typing mechanism? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]