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. end quote 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. end quote 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]
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 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:
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 Cocoa/Cocoa.h
@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 Cocoa/Cocoa.h
@interface DummyClass : NSObject {
}
- (void) printFloat:(float)pF;
// DummyClass.m
#import DummyClass.h
@implementation DummyClass
- (void) printFloat:(float)pF {
}
// CallingClass.h
#import Cocoa/Cocoa.h
#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 Cocoa/Cocoa.h
#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 Cocoa/Cocoa.h
@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 Cocoa/Cocoa.h
@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 Cocoa/Cocoa.h
#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
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]
Dynamic message typing problem
Hi,
It would be great if someone would kindly tell me what I'm doing wrong.
Something like the much simplified code below used to work under
Tiger in 10.4 running on antique 400 MHz G4.
The idea is that the program passes the id of an
anonTargetClassObject to a calling object which then sends a message
to that anonTargetClassObject id.
What seems to be happening is that I am not getting the compiler to
generate the correct type information for the float and unsigned char
message parameter.
The code is implemented in Leopard running on a mac Pro.
In the build info I have
Instruction scheduling = PowerPC G5 - I've tried several of the
options without success
Objective-C Garbage Collection = Required
Optimisation Level = Fastest, smallest
C language dialect = Compiler Default
Compile Sources as = Objective-C
Everything else is set to the default.
I'm sure I'm giving you more code than you need but here goes
===
//the .h and .m files of object to which the message is sent
#import Cocoa/Cocoa.h
@interface AnonTargetClass : NSObject {
}
- (void) printSimple;
- (void) printString:(NSString *)pS;
- (void) printFloat:(float)pF;
- (void) printInt:(int)pI;
- (void) printUnsignedChar:(unsigned char)pC;
- (void) printUnsignedCharRef:(unsigned char *)pC;
@end
#import AnonTargetClass.h
@implementation AnonTargetClass
- (void) printSimple;
{
NSLog(@AnonTargetClass printSimple =Hi from AnonTarget);
}
- (void) printString:(NSString *)pS;
{
NSLog(@AnonTargetClass printString = %@,pS);
}
- (void) printFloat:(float)pF;
{
NSLog(@AnonTargetClass printFloat = %7.3f,pF);
}
- (void) printInt:(int)pI;
{
NSLog(@AnonTargetClass printInt = %6d,pI);
}
- (void) printUnsignedChar:(unsigned char)pC;
{
NSLog(@AnonTargetClass printUnsignedChar = %6d,pC);
}
- (void) printUnsignedCharRef:(unsigned char *)pC
{
NSLog(@AnonTargetClass printUnsignedCharRef = %6d,*pC);
}
@end
//the .h and .m files of calling object
#import Cocoa/Cocoa.h
@interface CallingClass : NSObject {
}
- (void) callPrintSimple:(id)pId;
- (void) callPrintConstString:(id)pId;
- (void) callPrint:(id)pId zString:(NSString *)pS;
- (void) callPrintConstFloat:(id)pId;
- (void) callPrint:(id)pId zFloat:(float)pF;
- (void) callPrintConstInt:(id)pId;
- (void) callPrint:(id)pId zInt:(int)pI;
- (void) callPrintConstUnsignedChar:(id)pId;
- (void) callPrint:(id)pId zUnsignedChar:(unsigned char)pI;
- (void) callPrintConstUnsignedCharRef:(id)pId;
- (void) callPrint:(id)pId zUnsignedCharRef:(unsigned char *)pI;
@end
#import CallingClass.h
@implementation CallingClass
- (void) callPrintSimple:(id)pId
{
[pId printSimple];
}
- (void) callPrintConstString:(id)pId
{
[pId printString:@Hi from PrintConstString];
}
- (void) callPrint:(id)pId zString:(NSString *)pS
{
[pId printString:pS];
}
- (void) callPrintConstFloat:(id)pId
{
[pId printFloat:12.34];
}
- (void) callPrint:(id)pId zFloat:(float)pF
{
[pId printFloat:pF];
}
- (void) callPrintConstInt:(id)pId
{
[pId printInt:5];
}
- (void) callPrint:(id)pId zInt:(int)pI
{
[pId printInt:pI];
}
- (void) callPrintConstUnsignedChar:(id)pId;
{
[pId printUnsignedChar:222];
}
- (void) callPrint:(id)pId zUnsignedChar:(unsigned char)pCh;
{
[pId printUnsignedChar:pCh];
}
- (void) callPrintConstUnsignedCharRef:(id)pId;
{
unsigned char * tvarUnsignedChar= 123;
[pId printUnsignedCharRef:tvarUnsignedChar];
}
- (void) callPrint:(id)pId zUnsignedCharRef:(unsigned char *)pChRef;
{
[pId printUnsignedCharRef:pChRef];
}
@end
// main.m
#import Cocoa/Cocoa.h
#import AnonTargetClass.h
#import CallingClass.h
int main(int argc, char *argv[])
{
AnonTargetClass * anonObjToBeCalled = [[AnonTargetClass alloc]init];
CallingClass* callingObj= [[CallingClass alloc]init];
float tvarFloat = 6.54;
int tvarInt = 321;
unsigned char tvarUnsignedChar= 255;
NSLog(@Check the methods of AnonTargetClass);
[anonObjToBeCalled printSimple];
[anonObjToBeCalled printString:@String direct from main];
[anonObjToBeCalled printFloat:98.76];
[anonObjToBeCalled printFloat:tvarFloat];
[anonObjToBeCalled printInt:55];
[anonObjToBeCalled printInt:tvarInt];
[anonObjToBeCalled printUnsignedChar:tvarUnsignedChar];
[anonObjToBeCalled printUnsignedCharRef:tvarUnsignedChar];
NSLog(@End checking methods of AnonTargetClass);
NSLog(@calling the methods dynamically);
[callingObj callPrintSimple:
(id)anonObjToBeCalled ];
[callingObj callPrintConstString:
(id)anonObjToBeCalled];
// just testing the lack of coersion
[callingObj callPrint: anonObjToBeCalled zString:@This string
passed from main 1];
[callingObj callPrint: (id)anonObjToBeCalled
