А если вдруг запустит на двух- и более процессорном кристалле ?

Компилятор может и не будет ругаться (а зря), однако так делать нельзя. Причины озвучены выше.

Хорошо вас тут читать.. но.. мое мнение если можно "«Бывает ли у вас такие ситуации, когда слово, идиома или грамматическая конструкция иностранного языка никак не могут удержаться в голове, несмотря на то, что вы встречали её уже много раз и даже специально учили? А сколько процентов иностранных слов вы помните спустя месяц после их изучения? А спустя полгода? Сложно ли вам мотивировать себя на занятия иностранным языком?»
У меня на эти вопросы возникает только другой вопрос: А так ли оно мне надо, если я пользуюсь этими словами раз в пол года? Я лично против забивания мозга тем, что мне не сильно то и нужно."
как-то так примерно. Давно перестал запоминать все эти правила и стараться " типа красиво, в одну строку все". Мой код стал похож на "новичка" - разделяю все на строки не длиннее 80 символов (исключение - список инициализации конструктора), ставлю скобки где и не нужны. Зато не надо вспоминать 14 приоритетов и думать о sequnce point. Ну кто как хочет, только потом обычно с кодом разбираться самому и придется, и материть тоже самого себя. С cppreferencr.com тоже могу "офигенно красиво" написать, только вот потом подзабывается все это. Ну ладно, сорри что встрял в ученую беседу

Трудно Вам придётся когда надо будет поработать в команде с другими программёрами. ...у которых свои понятия.

Я тоже пишу максимально просто и без лишней головной боли.
Просто понимаю, какие конструкции к чему могут привести с точки зрения стандарта языка. А чтобы это начать понимать, пришлось не одну ложку дегтя съесть в других проекта)))

Имеем следующее

pSigRe = SigRe;
for (uint32_t i = FFT_N; i--; ) {
*pSigRe++ = log2f(*pSigRe) * 15.0515;
}

Если SigRe это массив, может следует к нему обращаться как к массиву.

// pSigRe = SigRe;
j=0;
for (uint32_t i = FFT_N; i--; ) {
SigRe[j] = log2f(SigRe[j]) * 15.0515;
j++;
}

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

Не считайте упрямством, хочу разобраться. Постинкремент переменной работает после того, как ее использовали. Следовательно, после того, как будет записано вычисленное выражение. Логично?


Можно и к массиву. Предполагаю, что для ARM это будет работать так же легко и быстро, как и по указателю. Но я люблю указатели. Деды так завещали.


Первое высказывание исключает второе. Если учесть, что оба неверные, следует, jcxz = трепач.

Нет, не так.
Постинкремент переменной не определён внутри выражения.
Рассмотрим пример:

По стандарту операция присваивания не является точкой следования, соответственно неизвестно, в каком порядке будут вычислены стороны выражения.
Рассмотрим первый пример. Для него порядок вычисления может быть одним из следующих:


Аналогично и в Вашем случае.

Сообщение отредактировал Arlleex - Feb 6 2018, 20:47

Компилятор использовал следующую команду для записи вычисленного выражения
*pSigRe++ = log2f(*pSigRe) * 15.0515;

STR r0,[r4],#4
Постинкремент

А окружение этой команды можно привести? До и после... Можно сказать, Вам повезло

После того как была выполнена конкретная операция, а не всё выражение. Постинкремент же относится к операции, а не ко всему выражению. Логично?


И что? какая разница какой командой он записал?
Он Вам написал что Ваше выражение можно понимать как:
pSigRe[0] = log2f(pSigRe[0]) * 15.0515;
pSigRe++;
так и:
pSigRe[0] = log2f(pSigRe[1]) * 15.0515;
pSigRe++;
И в результат компиляции выдал первый вариант. Хотя вполне справедливо мог и второй - это как ему удобнее.

Мог бы... Но не сделал. А сделал так, как мне и было нужно. Это я констатирую факт.
Переписать, чтобы инкрементировался указатель отдельным выражением, легко. Выше уже давно сделал.
Вопрос, почему CppCheck ругается, а Keil молча делает, как было задумано. Кто из них тупит?


Покажу оба варианта, ближе к обеду. И оптимизацию разную проверю.

Я думаю, если ассемблер данного конкретного контроллера поддерживает постинкремент указателей, и компилятор использует это свойство, то результат будет всегда один. Если же перейти на проц, где нет этой фичи (или уже не хватает регистров для указателей), результаты компиляции могут быть неоднозначными.
Как радиоинженер и непрофессиональный программист, я тоже предпочитаю не вспоминать приоритеты и не жалеть скобок.

Не знаю что за CppCheck, но он тут молодец, что предупредил. А Keil не молодец. Хотя может и молодец, что схавал, полагаясь на компетентность программиста (а иногда так и хочется наорать на компилятор "я знаю что я делаю, тварь!" ). Хотя и не молодец, хотя бы warning бы кинул...


Ассемблер тут совершенно ни при чем. Это полностью зависит от компилятора. Реализовано ли в системе команд постинкремент или нет, совершенно не важно, компилятор может спокойно разбить постинкремент на несколько инструкций.
Я не понимаю одного - если в стандарте четко написано о таких вещах, зачем намеренно создавать себе проблему "кодированием через пробы и ошибки"? Ведь даже элементарное включение оптимизации может привести совершенно к другому порядку инструкций, и гарантировать равнозначное поведение в данном случае невозможно.

А еще правильнее написать авторам cppcheck и задать вопрос напрямую.