Re: Advice needed about a possible bug in NSMethodSignature or NSInvocation
Re: Advice needed about a possible bug in NSMethodSignature or NSInvocation
- Subject: Re: Advice needed about a possible bug in NSMethodSignature or NSInvocation
- From: Thomas Lachand-Robert <email@hidden>
- Date: Wed, 10 Mar 2004 19:08:32 +0100
Le 10 mars 04, ` 16:49, Chris Kane a icrit :
On Mar 3, 2004, at 4:39 PM, Thomas Lachand-Robert wrote:
The small test program below do exactly that, it calls two methods
with equal return type, one declared as (NSObject<NSCopying>*) and
the other as (Copy*) after a "typedef NSObject<NSCopying> Copy". No
problem with a standard call, but I get the following output for a
call via an NSInvocation:
Signature for method 'test1' = @, result address = 0x9a004.
Signature for method 'test2' = ^{NSObject=#}, result address =
0x30d510.
You get different results because the two type signatures created by
the compiler mean different things. Check out the typedef of 'id' in
the /usr/include/objc/objc.h: a pointer to a struct containing a
pointer to a class. Basically, id ('@') is a special case meaning
object, in interpreting the types, and pointer-to-Class[-pointer] or
pointer-to-struct-containing-Class[-pointer]-as-first-member are
handled more literally.
This is probably because you are separating the pointer from the type
declaration. You are returning Copy *, which means that in that
particular case you are returning a pointer to a Copy but in other
cases you might use Copy without using a pointer to it. I think the
behavior here is arguably correct, without too much effort, or if not,
the That's Just The Way It Works Principle would apply.
Try changing this:
typedef NSObject<NSCopying> Copy;
to this:
typedef NSObject<NSCopying> *Copy;
and change uses of Copy.
Thanks a lot for your answer, but I have to disagree there. Usually in
C "typedef SomeType SomeName" has the same effect than "#define
SomeName SomeType". For instance "typedef NSObject Object" is the same
than "#define Object NSObject".
Your suggestion implies it should be correct to have a different
behavior with something like NSObject<NSCopying>.
Maybe it was not clear in my first message, but the problem comes ONLY
from the protocol; that is "typedef NSObject Copy" causes no problem at
all. (I don't do that usually, but I tried in my test case.) So I don't
understand how this can be related to the definition of id in
/usr/include/objc/objc.h. BTW the compiler don't complain, and the
behavior of all other parts of the program is as expected. ONLY
NSInvocation is implied.
About your remark on Copy* different from Copy, I just don't get it:
does returning NSObject* means that you can sometimes use NSObject
without using a pointer to it? And again, the point here is that there
is no problem in returning NSObject* (with or without a typedef), but
in returning NSObject<NSCopying>*. I obviously prefer the original
typedef, for consistency reason, and because it allows me to change
"Copy" to a true class if needed later on.
Yours,
Thomas Lachand-Robert
********************** email@hidden
<< Et le chemin est long du projet ` la chose. >> Molihre, Tartuffe.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.