Вам необходимо связать handelChange
с this
или преобразовать handelChange
в функцию стрелки.
constructor(props) {
super(props)
this.handelChange = this.handelChange.bind(this)
}
Как еще можно утверждать (foo == bar);
компилировать до нуля, когда Определен NDEBUG
?
Я не являюсь языковым дизайнером, но я отвечу: "Почему нет?" С точки зрения языкового дизайна, необходимо, чтобы правила (т.е. грамматика) были как можно более простыми.
Не говоря уже о том, что «пустые выражения» используются, то есть
для (i = 0; i Будет мертвое ожидание (не очень хорошее использование, но, тем не менее, использование). РЕДАКТИРОВАТЬ: Как указано в комментарии к этому ответу, любой компилятор, достойный его соли, вероятно, не ] занят ожиданием в этом цикле и оптимизировать его. Однако, если бы было что-то более полезное в самой голове (кроме i ++), что, как я видел, было сделано (странным образом) с обходом структуры данных, то я думаю, что вы все равно могли бы создать цикл с пустым телом (используя / злоупотребляя конструкцией "for").
Очевидно, что мы можем что-то сказать как
for(;;) {
// stuff
}
Кто бы мог жить без этого?
Вы хотите иметь возможность делать что-то вроде
while ( fnorble(the_smurf) == FAILED )
;
, а не
while ( fnorble(the_smurf) == FAILED )
do_nothing_just_because_you_have_to_write_something_here();
Но! Пожалуйста, не пишите пустое утверждение в одной строке, например:
while ( fnorble(the_smurf) == FAILED );
Это очень хороший способ запутать читателя, так как легко пропустить точку с запятой и, следовательно, думать, что следующий ряд - это тело цикла. Помните: программирование - это общение - не с компилятором, а с другими людьми, которые будут читать ваш код. (Или с собой три года спустя!)
Честно говоря, я не знаю, является ли это реальной причиной, но я думаю, что есть смысл подумать об этом с точки зрения разработчика компилятора.
Большие порции Компиляторы создаются автоматическими инструментами, которые анализируют специальные классы грамматики. Кажется очень естественным, что полезные грамматики допускают пустые выражения. Кажется ненужной работой по обнаружению такой «ошибки», когда она не меняет семантику вашего кода. Пустой оператор ничего не сделает, так как компилятор не будет генерировать код для этих операторов.
Мне кажется, что это всего лишь результат «Не исправляйте то, что не сломано» ...
Вероятно, наиболее распространенным случаем является
int i = 0;
for (/* empty*/; i != 10; ++i) {
if (x[i].bad) break;
}
if (i != 10) {
/* panic */
}
while(1){
; /* do nothing */
}
Бывают моменты, когда ты хочешь сидеть и ничего не делать. Встроенное приложение, управляемое событиями / прерываниями, или когда вы не хотите, чтобы функция выходила, например, при настройке потоков и ожидании первого переключения контекста.
Пример: http://lxr.linux.no/linux+v2.6.29/arch/m68k/mac/misc.c#L523