Re: -performSelector: exception... in one build configuration
Re: -performSelector: exception... in one build configuration
- Subject: Re: -performSelector: exception... in one build configuration
- From: Christiaan Hofman <email@hidden>
- Date: Sat, 05 Nov 2011 01:10:50 +0100
On Nov 4, 2011, at 20:56, Steve Christensen wrote:
> On Nov 4, 2011, at 9:11 AM, Christiaan Hofman wrote:
>
>> On Nov 4, 2011, at 16:03, Steve Christensen wrote:
>>
>>> On Nov 4, 2011, at 3:44 AM, Christiaan Hofman wrote:
>>>
>>>> On Nov 4, 2011, at 7:13, Steve Christensen wrote:
>>>>
>>>> So how DID you create the C-array of structs?
>>>
>>> struct MyStruct
>>> {
>>> SEL selector;
>>> ...
>>> };
>>>
>>>
>>> static const MyStruct kArrayOfStructs[] =
>>> {
>>> {
>>> @selector(foo),
>>> ...
>>> },
>>> {
>>> @selector(bar),
>>> ...
>>> },
>>> ...
>>> };
>>>
>>> ...
>>>
>>> - (void) crashingCode
>>> {
>>> ...
>>> [[NSUserDefaults standardUserDefaults] performSelector:kArrayOfStructs[i].selector];
>>> ...
>>> }
>>
>> This should not work. It fails for me with an error saying "Initializer element is not a constant". I don't know why you don't get that error, perhaps you can and have turned it off using some build setting.
>
> Nope, I turn on all the warnings I can so that I make sure that at least the obvious goofs get cleaned up. But as David pointed out in another reply, it doesn't complain if you're building Obj-C++, which I am.
>
>> But it's certainly not correct. For one thing, I don't think you can be sure that the runtime has been set up at the time that this variable is created and initialized.
>
> That appears to be irrelevant for at least the case I'm seeing since the selector value is known at compile time. When I look at the assembly code for that file, it shows the structure fields fully filled out, including the selector fields.
>
If you'd read what I wrote you'd know you're wrong here. It IS relevant, because a selector is REGISTERED, and registration happens at RUN TIME. So any value that is known at compile time CANNOT BE RIGHT. In particular, your values are wrong. So let me make this very explicit: the fact that there is a value does not mean that it is the CORRECT value.
>> And I don't know (neither do you) whether you can trust whatever @selector() does at that point.
>
> At least for the Obj-C++ case, @selector() appears to be generating the SEL value at compile time.
>
Not the SEL value, just a C-string that looks like a SEL.
Christiaan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden