Косяк у Кейла, Препроцессор не следит за скобками Опции

[ViKo]

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

Код

#define SYSCLK        48000000ULL
#define _NS    1
#define _US    1000
#define _MS    1000000
#define _SS    1000000000

#define DELAY(VALUE, UNIT);    \
  /* DelayFourCycles(VALUE * UNIT * (SYSCLK / 1000000) / 4000); */ \
  DelayFourCycles((SYSCLK / 1000000) * VALUE * UNIT / 4000);

  DELAY(50, _SS);

Так вот, когда сделал, как в закомментированной строке, Кейл ругается на то, что число не влазит в int. И загружает в функцию абы что. Если же сделать, как в строке без комментария, то все вычисляется правильно. Выходит, Кейл видит что последовательность операций равнозначна, что со скобками, что без, и лихо их отбрасывает. Возникает переполнение. Хотя не понятно, отчего возникает, 64 битов должно хватать (на компьютерном калькуляторе хватает). Как будто у Кейла не 64-битовое вычисление, а меньшее.

[aaarrr]

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

1. Когда выражение изначально представляет собой константу:

Код

while(1) {...}

if(123) {...} /* Правда, выглядит ужасно? */

Тут предупреждение явно ни к чему.

2. Когда выражение обращается в константу на этапе компиляции:

Код

unsigned int x;

if(x >= 0) {...}

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

Оформление бесконечного цикла - это уже дело вкуса программиста. Я, пожалуй, соглашусь, что for(;;) {..} лучше, просто
на основании того, что if(1) {...} мне представляется ужасным. Но while(1) {...} все же ни малейшего отторжения не вызывает.

[GetSmart]

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

Например:
if (1) ... до препроцессора могло быть if (Expr) ..., где Expr определялось дефайном. Вся конструкция вызывала бы опциональную инициализацию периферии, например. В отличие от #if допускает даже рунтайм-условие (вроде Fclk > 100). И безусловно должно допускать простейшую константу или выражение, вычисляемое на этапе компиляции. Неполиткорректно называть это ужасным. Ну а что позволено if-у, то юпитеру while и подавно. ИМХО всё вполне читабельно.Так же ИМХО, должно вызывать ремарку компилятора, если условие известно на этапе компиляции.

Смысла в таких конструкциях более чем достаточно. Хватит вопить про бессмысленность и всякий криминал. Даже просто if (0 или 1) (это без вмешательства препроцессора) могло быть промежуточной (но 100% рабочей) версией кода, расчитанной на изменение условия в дальнейшем. Вобщем код опционален и этот блок можно включить или выключить по необозначенному явно условию. Смысл в константах есть. Нарушений стандарта нет.

Сообщение отредактировал GetSmart - Aug 29 2015, 17:31

[zltigo]

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

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

[GetSmart]

Писатели не могущие четко выражать свои мысли компилятору получают такой-же нечеткий результат.

На while (const) ?

Критикуйте конструктивней и точечней. Необоснованность ругательств компиляторов нужно разбирать в каждом конкретном случае.

Компиляторописатели тоже лажают. Встречал граблю когда в конструкции if (0) стоит метка и вне if-а, ниже по коду, стоит на неё переход. Виновен компиляторописатель. Необычный код, но по стандарту ошибки нет.

Сообщение отредактировал GetSmart - Aug 29 2015, 17:58

[zltigo]

Критикуйте конструктивней и точечней.

Читайте внимательнее и не фантазируйте. Warning на constant expression это не единственный warning выдаваемый компиляторами из тех, ктороые нерадивые любят давить.

Кстати, я никогда не пишу #if (0) или #if (1), а только #if (true), #if (false)

А смысл? Тем более для препроцессора, для которого это никаким боком не ключевые слова, как впрочем и для произвольного (не C11? C99?) Си компилятора. Только в свежих стандартах true и false определены и в том числе для препроцесора.

Зато какие прелесные эффекты будут с каким-нибудь GCC препроцессором, который молча без всяких предупреждений подсунет вместо недефинированого true нолик.

[ViKo]

А смысл? Тем более для препроцессора, для которого это никаким боком не ключевые слова, как впрочем и для произвольного (не C11? C99?) Си компилятора. Только в свежих стандартах true и false определены и в том числе для препроцесора.

Зато какие прелесные эффекты будут с каким-нибудь GCC препроцессором, который молча без всяких предупреждений подсунет вместо недефинированого true нолик.

На то есть #include <stdbool.h> А смысл - лично для меня, эстета. "Истина" круче "единицы".

[zltigo]

На то есть #include <stdbool.h> А смысл - лично для меня, эстета. "Истина" круче "единицы".

Повторяю - ЕСЛИ ЕСТЬ, а есть только начиная, помнится, с C99, а если нет, то...

[ViKo]

Повторяю - ЕСЛИ ЕСТЬ, а есть только начиная, помнится, с C99, а если нет, то...

Напомните, сколько лет прошло с 1999 года? Что ж цепляться за старое? В том, чем я пользуюсь, есть. Прикажете забить (забыть)?

[zltigo]

Напомните, сколько лет прошло с 1999 года? Что ж цепляться за старое?

Абсолютно согласен, что использовать следует C99. Но жизнь, есть жизнь. Я вот до сих пор вынужден пользовать И компиляторы не поддерживающие C99. C99 просто нет. Есть и глупые варианты, например, пару месяцев назад начал рабтать с котроллерос с ядром BA22. Есть GCC toolchain весь из себя C99. Но весь говнокод идущий с контроллером компилируется не в С99. Какого черта - вопрос не ко мне, а к "программистам" тупо по умолчанию собравших. А там действительно чистый говнокод, который-бы сто лет не читал-бы, но он идет, в соответствии с новейшими тенденциями, ВМЕСТО документации .

Зачем? Потому что это нормальная языковая конструкция.

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

Список компиляторов в студию

Не сочтите за труд ознакомится с ранее данным ответом на этот вопрос.

Сможете опровергнуть?

Частные случаи на то и частные, что не всегда эквиваленты общим. По этой причне в стандарте эти понятия и РАЗДЕЛЕНЫ и constant expression в контесте while() НЕ упоминаются, в отличие, кстати, от for()

Специально посмотрел: использую оба варианта, но чаще while(1). Объясняется это очень просто - в старые времена
компиляторы под ARM отвратительно компилировали циклы for, из-за чего повсеместно использовал do-while.

У меня еще для одного изделия на AM186CC еще живет BCC 3.1 за него, правда уже не уверен, но 2.0 для while( 1 ) генерил лишний код в цикле, в отличие от for( ; ; ).

[GetSmart]

Не сочтите за труд ознакомится с ранее данным ответом на этот вопрос.

По ключевому вопросу whille (const) всё прояснилось. Остальное не интересно. Превращать ремарки в варнинги и пугать народ не надо.

Частные случаи на то и частные, что не всегда эквиваленты общим. По этой причне в стандарте эти понятия и РАЗДЕЛЕНЫ и constant expression в контесте while() НЕ упоминаются, в отличие, кстати, от for()

Вхождение во множество частного случая не обязано упоминаться. Упоминаются только исключения частных случаев. Для ограничения множества (выражений) в каком-то типе цикла нужно это явно описывать с обоснованием. Т.к. в цикле for все три аргумента независимы друг от друга, то управляющее выражение ничем не должно отличаться от других циклов. Но, судя по всему, в стандарте оно отличается тем, что отсутствие выражения в нём принимается за истину. И это странно, во-первых из-за нарушения симметрии. Не читал стандарт, но возможно необоснованного. Кроме того, отсутствие чего-то логичнее принимать за 0.

Упд.
Похоже на за уши притягивание этого типа цикла к бесконечным.

Сообщение отредактировал GetSmart - Aug 30 2015, 10:03

[zltigo]

Превращать ремарки в варнинги и пугать народ не надо.

Деление на ремарки и варнинги весьма условное и не у всех компиляторов. У MS нет: https://msdn.microsoft.com/en-us/library/6t...h(v=vs.90).aspx
А у некоторых нет ни того ни другого они пишут "Diagnostic 279: controlling expression is constant".

[GetSmart]

Деление на ремарки и варнинги весьма условное и не у всех компиляторов.

....

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

Ремарка это скорее подсказка. Качество кода подсказками не измеряется.