[ViKo 1]

Значит msdn тоже врет, все врут! Но коли так, покажите свою "правильную" табличку B)

Посмотрите у Кернигана с Ричи, и у Шилда в книгах.

[Forger 17]

Посмотрите у Кернигана с Ричи, и у Шилда в книгах.

Чтобы не быть голословным, приведите сюда конкретные цитаты из этих книг, а конкретно приоритеты оператора постфиксного инкремента ++ и оператора [].

[k155la3 26]

. . . Оператор "[]" имеет приоритет, равный приоритету оператора "++". . .

Это не так, приоритеты у них одинаковые ))

Да, надо будет перечитать "классику". И делать это постоянно :)

+ порядок "разбора" строки компилятором слева направо, как обычные операторы +-*/

Ни у кого не возникает вопроса в результате выражения A/B*C

 

 

 

 

[ViKo 1]

Чтобы не быть голословным, приведите сюда конкретные цитаты из этих книг, а конкретно приоритеты оператора постфиксного инкремента ++ и оператора [].

Я думаю, вы в состоянии самостоятельно полистать книги. Стр. примерно 66 - 69. Для пост- и пре- ++ и - - там нет различий, это, видимо, позже придумали словоблуды (стандартизаторы) и шарлатаны из MS. Кстати, в стандарте что на этот счет?

P.S. в стандарте на C99 я не нашел слова priority

[k155la3 26]

? z1 = ++ms[10] - синтаксис оператора для двух приведенных вариантов один. Тут могут быть грабли ?

 

динамический массив

int ms[100], z0, z1;

. . .

z = ms[10]++;

z1 = ++ms[10];

указатель на массив

int *ms = new int(100);

int z0, z1, z3;

. . .

z = ms[10]++;

z1 = ++ms[10];

z3 = (++ms)[10];

[aiwa 0]

а можно узнать что имел в виду писавший это? a++ или таки a[b++]

Чтобы узнать что имел ввиду писавший лучше спросить у самого писавшего.

Но написал он инкремент элемента массива, а не индекса.

 

? z1 = ++ms[10] - синтаксис оператора для двух приведенных вариантов один. Тут могут быть грабли ?

 

В простых выражениях ++a (или a++) никаких грабель не будет, причем независимо от порядка разбора.

 

В обоих случах "int *ms = new int(100);" и "int *ms = new int(100);" для компилятора различия сводятся

лишь к проверке типа, а сама переменная ms является по сути указателем в обоих случаях.

 

 

 

 

Изменено 15 июня, 2018 пользователем aiwa

[Forger 17]

Для пост- и пре- ++ и - - там нет различий, это, видимо, позже придумали словоблуды (стандартизаторы) и шарлатаны из MS. Кстати, в стандарте что на этот счет?

В стандарте С99 нет деления между постфиксным и префиксным инкрементом. Приоритет этих операций равен приоритету оператора [].

В стандартах C++ префиксный операторы перенесли в группу приоритетов ниже. Постфиксные остались на прежнем месте.

 

Т.е. как я и говорил постфиксный ++ имеет равный приоритет как и []. Не зависимо от стандарта. Не путайте народ!

 

Вот ссылки для сравнения:

http://ru.cppreference.com/w/c/language/operator_precedence

http://ru.cppreference.com/w/cpp/language/...ator_precedence

 

[ViKo 1]

Из Шилдта

Order of Evaluation

C does not specify the order in which the subexpressions of an expression are evaluated. This leaves

the compiler free to rearrange an expression to produce more

Highest ( ) [ ] –>.

! ~ ++ – – – (type) * & sizeof

* / %

+ –

<< >>

< <= > >=

== !=

&

^

|

&&

| |

?:

= += –= *= /= etc.

Lowest ,

Table 2 -8. Precedence of C Operators

 

Из К&R

Operators Associativity

() [] -> . left to right

! ~ ++ -- + - * (type) sizeof right to left

* / % left to right

+ - left to right

<< >> left to right

< <= > >= left to right

== != left to right

& left to right

^ left to right

| left to right

&& left to right

|| left to right

?: right to left

= += -= *= /= %= &= ^= |= <<= >>= right to left

, left to right

[Forger 17]

в стандарте на C99 я не нашел слова priority

Там используется другой термин: precedence

 

Вот любопытная ссылка:

https://www.geeksforgeeks.org/difference-between-p-p-and-p/

По сути a есть (*( a + b ))

[Herz 4]

Автор! В этом разделе 99% вопросов "по коду". Вы же не новичок, Вам должно быть это известно. Придумайте, пожалуйста, для темы более чёткое название.

[ViKo 1]

Там используется другой термин: precedence

Я по всякому искал, не нашел. Это удивляет.

P.S. но не очень усердно

C99.pdf

[k155la3 26]

IMHO: Использование постфиксных, и тем более - префиксных ++ в составе выражения ухудшает читабельность кода.

Смысла особого в такой "упаковке" не вижу. Компилятору - это филоетово, Будет ли оптимизация у исполнимого кода,

и к чему она приведет при таком написании - вопрос. Имело смысл, когда тактовая процессора измерялась килогерцами.

Хотя если задача - запутать читающего - то "самое-то" :)

 

[Forger 17]

Я по всякому искал, не нашел. Это удивляет.

Увы, в стандарте нет явной precedence table, есть только жалкие крохи, которые еще больше запутывают.

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

Поэтому подобные "мутные дела" лучше проверять на конкретном компиляторе.

Хотя, имхо, правильнее вообще избегать таких мутных дел и писать код более явно, чтобы любой компилятор правильно понял это. Да и читать такой код намного проще ))

[ViKo 1]

Хотя, имхо, правильнее вообще избегать таких мутных дел и писать код более явно, чтобы любой компилятор правильно понял это. Да и читать такой код намного проще ))

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

 

[Forger 17]

Но я имею таблицу приоритетов в файле, куда складываю "умные мысли",

Вот еще нашел любопытную таблицу: http://www.difranco.net/compsci/C_Operator...dence_Table.htm

Некоторые группы операторов тут имеют приоритет справа-налево, в отличие от большинства остальных групп.

 

Честно говоря, когда вижу в одном выражении смесь операторов "++/--" вместе с другими операторами, то стараюсь "от греха подальше" разделять их оператором ";" (на другую строку переносить).

Особенно это актуально при работе с указателями (операторы ->, *) - грабли с ними могут быть очень коварные :smile3046: