Мааленький вопрос про стандарт Си

Да

Это к чему?

OK. А в C++ это верно (в том числе, если = сделан как operator=)?

>если = сделан как operator=

Чего?

Да, в сях та же фигня. Я несколько раз напарывался на свои косяки в коде, где писал if (per = 0) {}, и долго тупил над кодом, пока не видел, что надо было ==, а не =. Вот за это я и люблю С и плюсы.

*в плюсах

> if (per = 0) {}

Разве современные конпиляторы не выдают предупреждение на такое говно?

Мб и выдает. Я не смотрю обычно на варнинги =) Больше доверяю своему мозгу, чем конпелятору.

gcc и g++ по дефолту не выдают. А вот с -Wall уже ругаются.

>. Я не смотрю обычно на варнинги =) Больше доверяю своему мозгу

/0

А ты проведи эксперимент:

taz = (bar = baz);
printf("...", taz);

и узнаешь!

какое значение будет у «а»?

в С++ это _МОЖЕТ_ быть не верным. смотря как определен оператор присваивания

> Я не смотрю обычно на варнинги =) Больше доверяю своему мозгу, чем конпелятору.

as a fellow KDE developer once said: «I don't do build tests before comitting; users generate better error messages than gcc»

Да?

нет, конечно, не эквивалентно

и не пиши так вообще никогда

> Верно ли

да. хотя могут быть нюансы, если bar — volatile. ЕМНИП, стандарт говорит, что результат присваивания равен присваиваемому значению, а не значению переменной, которой присваивали, после присваивания (что не одно и то же в случае mmio).

Zhbert: Да shty: нет, конечно, не эквивалентно

Вы меня запутали. Смутно помню, что результат присваивания a=b равен новому значению a. Если так, то, наверное, ответ — да. Пишут же

if (!(f = fopen(...))) { ... }

Меня интересует стандарт, а не поведение моего компилятора.

ЕМНИП, стандарт говорит, что результат присваивания равен присваиваемому значению, а не значению переменной, которой присваивали, после присваивания (что не одно и то же в случае mmio).

А можно конкретный пример, когда это «не одно и то же»?

>Меня интересует стандарт, а не поведение моего компилятора.

Тоже верно. Но тогда нужно было не полениться послюнявить пальцы и открыть нужную страницу книжки по Си.

g++ выдает ошибку, если «type result = func ()» — не единственное выражение под скобками.

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

Но что-то похожее на реплику arsi я читал: там было что-то вроде «left value, но не lvalue». Я такое не умею парсить.

Ну, в общем-то, я разобрался. Хоть тут были и несовместимые ответы, поверил большинству и arsi, который, судя по ответу, вроде бы разбирается в теме. Резюме: в сях на обычных переменных (не volatile и пр.) f(a=b) эквивалентно a=b;f(a), эквивалентно a=b;f(b). В С++ даже на обычных переменных это может быть не верно — зависит от конкретного оператора присваивания. Так?

> А можно конкретный пример, когда это «не одно и то же»?

конечно можно:

foo(bar = baz);

не одно и то же, что и

bar = baz;
foo(bar);

если bar — volatile и алиасит mmio.

> если bar — volatile и алиасит mmio.

Ты сгенерированный код проверил?

По стандарту присваивание является выражением и результат этого выражения равен результату вычисления выражения в правой части присваивания.

А вот a=b;f(b) уже не хорошо. Пример b - double, a - char. Поведение f(a) и f(b) может быть различным.

В стандарте есть четкий пример, когда (с=getchar()) == EOF не является корректным именно из-за того, что выполняется присваивание. Не надо забывать про преобразованиях типов.

Резюме: в сях на обычных переменных (не volatile и пр.) f(a=b) эквивалентно a=b;f(a), эквивалентно a=b;f(b). В С++ даже на обычных переменных это может быть не верно — зависит от конкретного оператора присваивания. Так?

Нет, С и С++ в указанном arsi случае ведут себя одинаково. Другое дело что это имеет смысл только в ядре или когда ОС вообще нет. В С++ кривая перегрузка оператора «=» тоже даст разные результаты.

> Ты сгенерированный код проверил?

> сгенерированный код

> сгенерированный

каким компилятором? или есть компилятор, который, по авторитетному заявлению ansi/iso/iec, всегда генерирует код, на 100.00000% соответствующий стандарту?

Чтобы быть уверенным в эквивалентности придётся читать выхлопы всех компиляторов подо всеми архитектурами во всех условиях.

> ЕМНИП, стандарт говорит, что результат присваивания равен присваиваемому значению, а не значению переменной, которой присваивали

Не может такого быть, просто потому, что выражение присваивания имеет тип lvalue.

> OK. А в C++ это верно (в том числе, если = сделан как operator=)?

Нет. operator= совершенно не обязан возвращать *this.

> каким компилятором?

Да хоть каким-нибудь.

или есть компилятор, который, по авторитетному заявлению ansi/iso/iec, всегда генерирует код, на 100.00000% соответствующий стандарту?

Если найдется компилятор, генерирующий разный код, это будет значить, что минимум один специалист по компиляторам с тобой согласен.

Очевидно, что эквиваленто. Если требуется объяснение по стандарту, то:

6.5.2.2.4: Аргумент может быть выражением любого типа. При вызове аргументы оцениваются и каждому аргументу назначается параметр...

6.5.1: Выражение - последовательность операторов и операндов, которое соответствует вычислению значения ...

6.4.6 : ... содержит таблицу операторов ...

6.5.6: Для сложения требуется, чтобы оба операнда были арифметическими типами или чтобы один был указателем на объект, а второй имел целый тип.

> Не может такого быть, просто потому, что выражение присваивания имеет тип lvalue.

всё верно: «выражение присваивания имеет тип lvalue», а не значение. и об этом сказано в 6.5.16 (третий пункт) iso/iec 9899:1999.

> всё верно: «выражение присваивания имеет тип lvalue», а не значение.

char a = long_int * double_value;

и давно ты стал наркоманом?

Тебя это беспокоит? Хочешь об этом поговорить?

Да, в сях та же фигня. Я несколько раз напарывался на свои косяки в коде, где писал if (per = 0) {}, и долго тупил над кодом, пока не видел, что надо было ==, а не =. Вот за это я и люблю С и плюсы.

Записывайте константу слева, компилятор вас предупредит об ошибке:

if(0 = var) { }

> Пишите на Java, компилятор вас предупредит об ошибке

> Пишите на Java, компилятор вас предупредит об ошибке

Ага, особенно в случае с булевыми переменными..

Пишите на Java, компилятор вас предупредит об ошибке

«Ошибка: ты пишешь на Java»?

Да.