неопределенное поведение — C ++ непоследовательные модификации для итераторов
У меня есть следующий код в одном модульном тесте для итераторов:
EXPECT_TRUE(++it != it++);
куда it соблюдает требования стандартного итератора.
Насколько я знаю 2 модификации одной и той же переменной в одной и той же точке последовательности — это неопределенное поведение (!= не точка последовательности).
Учитывая оба operator++ версии являются функциями, которые имеют return утверждение (точка последовательности) применимо ли неопределенное поведение в этих случаях? Если нет, почему я получил "Multiple unsequenced modifications to it" предупреждение о компиляторе Apple LLVM 5.0?
Что происходит, когда функции встроены (скорее всего, они будут!)?
Решение
Во-первых, в некоторых случаях «итератор» может быть просто typedef в
указатель, поэтому не будет точек последовательности (или в C ++ 11,
операции не будут упорядочены) в выражении, и у вас есть
неопределенное поведение.
Если ++ оператор перегружен функцией, вы делаете
иметь указатель последовательности как при вызове функции, так и
когда он вернется. С другой стороны, порядок, в котором
Вызванные функции до сих пор не определены, поэтому результаты
сравнение не уточняется.
Другие решения
Хотя поведение не является неопределенным, если два оператора являются вызовами функций, они оцениваются в неопределенном порядке: компилятор может сначала оценить ++it а потом it++ или наоборот. Результаты скорее всего разные. Тест предполагает порядок слева направо, но это не гарантируется.
Независимо от того, являются ли функции встроенными, не имеет значения: встраивание — это оптимизация, то есть не разрешается изменять значение четко определенных программ. Конечно, при вставке вещей компилятор может в конечном итоге сделать разные выборы в отношении порядка вычисления. Тем не менее, компилятор может делать разные выборки каждый раз, когда его вызывают.
Дело в том, что если это происходит в одной и той же последовательности … Точка секвенции jsut завершает последовательность, так что вы делаете именно то, что вы уже сказали, вы сделали модификацию той же переменной в рамках того же вызова, которая не вырезать по точке последовательности.