Я тут перевожу чужой код на новую платформу. Встретился такой кодкак компилятор это увидит g_sPreset++ или g_sPreset[g_uiCounterPush++] ?

Первое. Что логично.

я понял. спасибо. судя по коду этот п...рограмист хотел таки приращивать g_uiCounterPush. хотя это то же самое.

Ээээ... Что "то же самое"?

еще такой вопрос
в aaa.h файле определено

а в aaa.c файле
#define _MENU_C
есть шанс что дефайн будет виден в aaa.h файле?


результат будет тот же. мы сместимся на один адрес вперед. .... ах да. ошибся. не то же самое.

Да, в случае
#define _MENU_C
#include "aaa.h"


Нет, a[b]++ и a[b++] разные по смыслу

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

интеллектуалам не понятно.
Переписываем
a[b]++;
в виде a[b] = a[b] +1;
По приоритету [] существенно выше чем оператор инкримента.

См. приоритеты операторов. Оператор "[]" имеет приоритет, равный приоритету оператора "++".
При равных приоритетах работает правило "слева направо". Т.е. сначала выполнится оператор [], а затем ++.
Однако, в подобных не очевидных ситуациях, имхо, лучше писать явно: g_sPreset[g_uiCounterPush] = g_sPreset[g_uiCounterPush] + 1;


Это не так, приоритеты у них одинаковые ))
Я тоже так думал, пока не глянул в "табличку" (см. ссылку выше)

это не я писал. писал начинающий програмист. я не знаю что он имел ввиду. но сдается мне он далек от таких изысков g_sPreset[g_uiCounterPush] = g_sPreset[g_uiCounterPush] + 1;хотя...черт его душу разберет...

А сам этот "программист" куда-то пропал?

Приоритеты у них разные, а табличка у вас неправильная.
Не "существенно выше" , а на одну позицию.

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

Народ, вы чего? Там все однозначно безо всяких толкований. a[b++] - инкрементим индекс, не трогая элемент массива, a[b]++ - инкрементим элемент, не трогая индекс. Любой другой вариант уже начинает попахивать нарушением MISRA C Rule 12.2

И то верно

Честно говоря, я решил, что речь идет про трактовку компилятором g_sPreset[g_uiCounterPush]++: либо (g_sPreset[g_uiCounterPush])++ либо (g_sPreset++)[g_uiCounterPush].


Если все же по теме, то ясен пень, что сначала выполнится то, что внутри оператора [ ], а потом и сам оператор [].

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

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

Да, надо будет перечитать "классику". И делать это постоянно
+ порядок "разбора" строки компилятором слева направо, как обычные операторы +-*/
Ни у кого не возникает вопроса в результате выражения A/B*C

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

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

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

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

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



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

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

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

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

Вот ссылки для сравнения:
http://ru.cppreference.com/w/c/language/operator_precedence
http://ru.cppreference.com/w/cpp/language/...ator_precedence

Из Шилдта


Из К&R

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

Вот любопытная ссылка:
https://www.geeksforgeeks.org/difference-between-p-p-and-p/
По сути a[b] есть (*( a + b ))

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

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

IMHO: Использование постфиксных, и тем более - префиксных ++ в составе выражения ухудшает читабельность кода.
Смысла особого в такой "упаковке" не вижу. Компилятору - это филоетово, Будет ли оптимизация у исполнимого кода,
и к чему она приведет при таком написании - вопрос. Имело смысл, когда тактовая процессора измерялась килогерцами.
Хотя если задача - запутать читающего - то "самое-то"

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

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

Вот еще нашел любопытную таблицу: http://www.difranco.net/compsci/C_Operator...dence_Table.htm
Некоторые группы операторов тут имеют приоритет справа-налево, в отличие от большинства остальных групп.

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

Что в данном конкретном примере нечитабельно?
Просто и наглядно: если значение в первом массиве меньше, чем соответствующее значение во втором, увеличиваем это значение.
Как это можно понять по-другому?!

А тема занятная получилась. Выяснилось, что приоритет операций в стандарте C99 явно не описан (наверное, его можно восстановить из форм Бэкуса-Наура, но уж больно лень) и он отличается (!) от приоритетов C++.
Хотя, конечно, стандарты C++ писали неглупые люди и про совместимость они подумали. Лично я ни разу не наступил на грабли, пользуясь им в этой части при написании сишного кода.

В данном и конкретном все понятно. (Если речь о том, что в первом посте)
Я в смысле применения к выражениям,

на что IAR выдает
Оттранслировалось ли ЭТО в код не проверял.
Может кто более удачный пример "эффективного кода" приведет, не выдающего warning, error, но нечитабельного.

За этим лучше сразу сюда: https://www.govnokod.ru

Неоднозначность результата компилирования и читабельность кода - суть вещи разные.
Приведенный Вами пример (a = b++ * 2 + b;) очень даже читабельный, хотя и неоднозначный.

Неясно, что подразумевается под термином "читабельный": умение читать код или умение понимать прочитанное?
Второе подразумевает явное знание работы компилятора и его действий.
Если же поведение компилятора в том или ином случае сложно предсказать, то как ни старайся именовать курицу павлином , все равно курицей она так и останется

"Читабельность" - это совершенно субъективная инстанция, а работа компилятора - объективная.

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

Хотя пример лучше поменять на "а = b++ *2 + sin( b ); потому что старый можно оптимизировать в "а = b++ * 3;" воспользовавшись неоднозначностью порядка"

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

Потому возникает риторический вопрос: есть ли вообще смысл анализировать подобный "код", когда сходу сразу понятно, что нифига не понятно? ...

А всего-то достаточно добавить несколько пар скобок или операторов ";" с соотв. переносом строки, чтобы напрочь закрыть любую "необъективность" даже самого "упоротого" кода.