Задачка с башорга

[romy4]

я спрашивал про этот баг (как мне объяснили, это не баг) на
http://bugs.php.net/bug.php?id=41373

There is one important rule: Don't change the value of a variable more
then one times between sequence points

 

[Сергей Тарасов]

Да, и с O0 и с O2 всегда "14".
Действительно странно... Про ссылку хорошая идея... Нужно проверить...

 

[romy4]

algo
в Си, в отличии от ПХП, подставляется адрес переменной, а не ее значение. на асме, сгенереном из такого кода это выглядело б примерно так:

mov [i],5 ;заносим по адресу переменной i 5
inc [var_i]   ; увеличиваем значение по адресу на 1 (++i)
inc [var_i]
mov ax,[var_i] ;берем левое значение возле знака +
mov dx,[var_i] ;берем правое значение возле знака +
add ax,dx ;складываем их
mov [var_i],ax ;заносим в переменную i получившееся значение

 

[Сергей Тарасов]

Интересно то, что

#include<iostream>

int main(int argc, char** argv[])
{
int i = 5;
i = ++i;
std::cout << i << " ";
i+= ++i;
std::cout << i;
return 0;
}


выводит 6 14

-~{}~ 14.05.07 13:18:

Хотя тут вроде все понятно:
++i вычисляется раньше, чем i+=, поэтому получается 7+7

 

[romy4]

Сергей Тарасов
такой код и в пхп дает 6 и 14

 

[Сергей Тарасов]

А вот в начальном случае.... ммм?

 

[Фанат]

romy4
какой код в пхп дает 6 и 14?

Сергей Тарасов
В каком именно случае?

 

[romy4]

$i=5;
$i=++$i;
var_dump($i);
$i+=++$i;
var_dump($i);

 

[Сергей Тарасов]

#include<iostream>

int main(int argc, char** argv[])
{
int i = 5;
i = ++i + ++i;
std::cout << i;
return 0;
}

Хотя теперь все понятно...
i - это одна переменная для компилятора. У нее есть 1 адрес:
1) Делеаем инкремент. Получаем 6
2) Делаем еще раз инкремент. Получаем 7
3) Складываем. Получаем 14

Так в gcc. С точки зрения оптимизации - хорошо. С точки зрения соблюдения стандарта языка c - не знаю...

 

[Vladson]

Автор оригинала: Сергей Тарасов
Хотя теперь все понятно...
i - это одна переменная для компилятора. У нее есть 1 адрес:
1) Делеаем инкремент. Получаем 6
2) Делаем еще раз инкремент. Получаем 7
3) Складываем. Получаем 14

Так в gcc.

в Borland Turbo C++ тоже так

(если быть точным то вот кусок кода)

;
; int i = 5;
;
mov si,5
;
;i = ++i + ++i;
;
inc si
inc si
mov ax,si
add ax,si
mov si,ax

 

[Сергей Тарасов]

icc выдает 13

 

[romy4]

все компиляторы, выдющие 13 можно заносить в черный список

 

[Фанат]

Сергей Тарасов
Стандарты, по словам дискуссий, как раз рекомендуют избегать применения таких неоднозначных конструкций.

 

[Сергей Тарасов]

romy4

Скорее, наоборот, в gcc это плата за оптимальность, ибо с т.зрения теории программирования(функционального, императивного - какого угодно) должно быть 13

Фанат
Понятно, что стоит избегать.

 

[Фанат]

Я писал не про то что следует избегать, а про то, что говорят стандарты отвечал на твой вопрос.
с чужих слов, правда.

 

[dark-demon]

нет никакой "теории всея программирования" есть конкретные языки и конкретные интерпретаторы.
и давайте мы не будем приписывать одному из древнейших языков какие-то баги на основании того, что некоторые(!) его подражатели делают что-то по другому.

 

[romy4]

Сергей Тарасов
ну это спорный момент
так как по логике (моей конечно же) операции имеющие высший приоритет должны выполнятся в первую очередь. Это раз. И два, то что подстановка значений должна происходить в последнюю очередь из переменных. т.е. фактически использоваться ссылки на переменные, а не копии их значений. вот.

да и это не только в gcc так мой любимый ватком дает тоже рузультат 14.

 

[Сергей Тарасов]

dark-demon
Иди учи матчасть

 

[dark-demon]

Сергей Тарасов, конкретней, пожалуйста.

 

[Сергей Тарасов]

По поводу самой задачки: кто-нить может проверит в VisualStudio?
Тем, кто питает иллюзии, что багов в gcc нет - ошибается.

-~{}~ 14.05.07 15:26:

Автор оригинала: dark-demon
нет никакой "теории всея программирования" есть конкретные языки и конкретные интерпретаторы.
и давайте мы не будем приписывать одному из древнейших языков какие-то баги на основании того, что некоторые(!) его подражатели делают что-то по другому.

По поводу этого:

1) Есть теория программирования (Функционального, Эмпирического и т.п.)
2) Есть Стандарт языка c++, который, Рома (!), должен оговаривать такие ситуации. Если он не разрешает такие неоднозначности - это плохой стандарт и его нужно исправить.
3) Есть компиляторы в той или иной мере соответствующие этому стандарту.

В идеале, в стандарте не должно быть "пустых мест", чтобы разные компиляторы по-разному не "домысливали" такие неоднозначности.