2009-03-24 3 views
0

У меня возникла странная проблема с логической логикой. Должно быть, я делаю что-то глупое, но я не могу понять. В приведенном ниже коде firstMeasure.isInvisibleArea имеет значение true и measureBuffer1 равно нулю. Несмотря на то, что test1 оценивает значение NO по какой-либо причине, он все равно переходит в оператор if. Он работает нормально, если я использую прокомментированную строку. Любая идея, почему это происходит?Ошибка логической логики

BOOL firstVisible = firstMeasure.isInVisibleArea; 
BOOL notFirstVisible = !(firstMeasure.isInVisibleArea); 
BOOL measureBufferNil = measureBuffer1 == nil; 

BOOL test1 = measureBuffer1 == nil && !firstMeasure.isInVisibleArea; 
BOOL test2 = measureBufferNil && !firstVisible; 

if (measureBuffer1 == nil && !firstMeasure.isInVisibleArea) 
//if (measureBufferNil && !firstVisible)  
{ 
    //do some action 
} 

Update 1:

я изолировал проблему firstMeasure.isInVisibleArea как я полностью взял на себя немного measureBuffer!. Внутри isInVisible области небольшой расчет (он ничего не изменяет, хотя), но расчет использует self.view.frame. Я тоже возьму это из уравнения и посмотрю, что произойдет. Моя догадка заключается в том, что self.view.frame меняется между двумя вызовами isInVisibleArea.


Update 2: Это действительно проблема. Я добавил ответ более подробно ниже

+0

Я думаю, что я говорю для всех, когда говорю «этот код должен работать точно так же». Если, возможно, вы не забыли знак равенства в одном из ваших сравнений где-нибудь. Вы пробовали один шаг в Xcode? –

+0

Да, у меня есть. Для меня это тоже не имеет смысла. – Ian1971

+0

Я обнаружил, что он должен быть связан с областью firstMeasure.isInVisible, потому что я пробовал его без бита measureBuffer1.Я обновил вопрос – Ian1971

ответ

0

Моя догадка была правильной, она связана с изменением ракурса между вызовами в область firstMeasure.isInVisible.

Вся эта процедура вызывается в ответ на перемещение вида. Я думаю, что мне нужно получить значение firstMeasure.isInVisibleArea в начале метода и использовать его во всем.

Фуэ. Логическая логика не нарушена. Все в порядке с миром.

Спасибо за все ваши данные

2

Если test1 оценивает ни к чему, как вы говорите, то падение test1 в если заявление:

if(test1){ 
    //see if this executes? 
} 

Смотрите, что это делает.

+0

Если я это сделаю, он правильно не попадает в условие if. – Ian1971

5

Если вы сомневаетесь, вы должны полностью заключить в скобки. Не рассматривая правила приоритета, я думаю, что происходит следующее: = получает более высокий приоритет, чем == или & &. Так что попробуйте:

BOOL test1 = ((measureBuffer1 == nil) && !firstMeasure.isInVisibleArea); 
+0

== имеет более высокий приоритет, чем присваивание = http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_precedence –

4

В то время как вы, конечно, можете круглые скобки, вы также должны знать, что nil объектов оценки для булева NO и не нулевые объектов оценки для булева YES. Поэтому вы можете так же легко написать это:

BOOL firstVisible = firstMeasure.isInVisibleArea; 
BOOL notFirstVisible = !(firstMeasure.isInVisibleArea); 
BOOL measureBufferNil = measureBuffer1; 

BOOL test1 = !measureBuffer1 && !firstMeasure.isInVisibleArea; 
BOOL test2 = measureBufferNil && !firstVisible; 

if (measureBuffer1 && !firstMeasure.isInVisibleArea) { 
    //do some action 
} 

Вы получите те же результаты. Я согласен с GoatRider. Всегда лучше заключить в скобки ваши условные выражения, чтобы уточнить, что вы действительно хотите, чем полагаться на приоритет оператора языка, чтобы сделать это за вас.

+0

Кто-то, кто сходит с ума по поводу безопасности типа, будет утверждать, что это просто счастливая случайность, и это полностью возможно для nil == NO && non-nil == YES, чтобы сломать некоторую другую архитектуру. Но я не сумасшедший. :-) – benzado

+0

Я полностью удалил измерение Buffer из уравнения. Проблема заключается в области firstMeasure.isInVisible. Я обновил этот вопрос своими последними результатами – Ian1971

Смежные вопросы