Стандарт языка Cи, надо читать и ПОНИМАТЬ написанное. for( ; ; ) абсолютно ОДНОЗНАЧНОЕ указание компилятору сгенерировать цикл БЕЗ проверки каких либо условий. Любой другой вариант уже требует проверки, а для выкидывания ненужной проверки уже наличия минимальной, но оптимизации. Начинать думать можете начать с того, что в в примерах стандарта вечный цикл for( ; ; ) и нет ни одного while( CONST ) у K&R совершенно аналогично. Ни то ни другое не есть -

Знакомьтесь.

Это вообще странный авторитет, особенно в свете последней выдержки с преобразованием типов....


Надо, и в нем нет запрета на конcтрукцию while(0) и while(1), ровно как и нет неоднозначного толкования как она будет выполнена.

Ошибкой является утверждение что это "принципиально ошибочное" выражение, оно даже потенциально не ошибочное, не то что принципиально....

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

Что вы сцепились на пустом. Я вот ни разу не использовал do { } while (0), и ничего. Программы работают, как задумано.

ща и вам достанется.... как вы могли ни разу не использовать?!!!

Ничего, с меня не убудет. Я авторитетом себя не считаю. Просто стараюсь писать аккуратно, не упуская нужных символов и не лепя ненужных. Пробелы не в счет, на них не экономлю. Например, если мне надо 1 << 7 + 16, то так и пишу. Хотя компилятор ругается предупреждением (не компилятор, а сама среда в Кейле значок ставит).

А VALUE я, пожалуй, в скобки возьму. Вдруг захочется мне (или кому-то другому) задать задержку в виде DELAY(2 + 2, _MS).

Уже писал - в стандарте нет запрета на использование русских матерных слов, тем неменее компиляторы не захотят компилировать такие выражения. Точно так-же, как компиляторы, пусть даже и не все, таки выдают предупреждения на while( CONST ). Так-что давайте Вы свой талант толкователя стандартов будете демонстрировать не мне.

ну как же нет? Есть стандарт формирования имен переменных и список ключевых слов. Ваши матерные выражения не попадают в множество которые возможно создать по данным правилам, потому их и нельзя использовать....


А вы не читайте....


а что за значок?

Восклицательный знак в желтом треугольнике напротив опасной строки. И подчеркивает красненьким опасное место.
При наведении мыши на подчеркнутое или на значок выдается:
warning: operator '<<' has lower precedence than '+'; '+' will be evaluated first

Какую ошибку? Условие/выражение может быть опционально вычисляемое в рунтайме. Или в какой-то опции проекта вычисляемое на этапе компиляции. Но место проверки условия задаёт тип цикла и его устанавливает программер исходя из оптимальности алгоритма, в том числе опционального удобства.

Подозревать препроцессор в перетрахе только выражений - мало. Это текстовый препроцессор и он может заменять любое место исходника. for (;;) мог быть перед препроцессором for (A;B;C) где A, B, C дефайном задавались пустыми или не пустыми. Потенциальность ошибки зацитированным методом компилятору не определить.

----

У zltigo могло бы быть большое будущее во главе какого-нибудь ЦБ, ну или будучи физиком-теоретиком. Умеет фундаментализировать инфляцию. Инфляцию отсутствия ошибок через повышение интеллекта компилятора. А так же переориентируя точку отсчёта на прокладку препроцессор.

Да ну! Вообще-то дело обстоит с точностью до наоборот.
1) break это выход из ЛЮБОГО цикла и городить для этого while(0) совершенно незачем.
2) именно ИСПОЛЬЗОВАНИЕ do while(0) в обертке макроса приводит в ПОБОЧНОМУ эффекту выхода по break из макроса ну СОВСЕМ не туда.



Ошибку того, что программист получил не то, что он думал. Ибо компилятор получил в качестве инструкции БЕССМЫСЛЕННОЕ, хотя и однозначное выражение. Дальше у компилятора два варианта - решить, что это написал не программист а "Джамшут" и не пытаться от него чего-либо еще добиваться, либо таки сообщить о подозрительном выражении.
Для определения "Джамшут"/программист у хороших компиляторов есть опция соответствующего warnig.

Это уже не потенциальные, а реально НЕОБОСНОВАННЫЕ обвинения и опасения. Контраргументация ранее была изложена в достаточном объёме.

------

Предлагаю желающим обсудить другой криминал. Не запрещено ли всевышним использование пустых фигурных скобок. А так же точки с запятой после скобок. Или внутри скобок обязательно должна стоять хотя бы точка с запятой. Часто циклы ожидания какого-то события делают пустыми, а в конце {};

Попробуйте убедить своей "контраргументацией" разработчиков компиляторов, которые ругаются на while(CONST). Мне рассказывать, что ныне принято писать дерьмокод и посему это "нормально", пожалуйста, не надо.
Из гарантированно мне известных это IAR и MS. Из гарантрованно плюющих помню только GCC.

А разве while(1) не сам всевышний написал?


IAR в СИ-коде не выдаёт error или warning на while (Const). Если читаете ремарки Иара, то не передёргивайте.

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

Всевышний, как написано в библии K&R а так-же в примерах в стандарте, в том числе и C11, написал совершенно однозначное for( ; ; ) Потом уже еретики начали писать while(1),while(2),while(3),.....,while(TRUE),while(true),while((_Bool)1) и так далее. Причем без всякой на то надобности.



Начние с MISRA - там МНОГО веселее . А с компиляторами все просто - если по какой-то причине, пусть даже по причине собвстенного несовершенства, компилятор сомневается, как понять, лучше пусть ПРЕДУПРЕЖДАЕТ. Я, если вдруг не смогу выразить мысль в однозначно понятной компилятору форме, лучше прагмой в этом месте сообщение подавлю, нежели получу неведомо что.

У цикла while только один аргумент - предусловие выполнения. Этот цикл логически естественнен для многих алгоритмов.


Компилятор Кейла ругается ошибкой на STM Rz!,{Rx-Ry} если Rz находется внутри сохраняемых регистров. Ошибка, не предупреждение. Писатели компиляторов слишком много себе позволяют.

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

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

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

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

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

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

Я что-то писал о неестественности цикла? Нет? Возражения только против того, что именно-то и УСЛОВИЯ быть-то и НЕ должно, ибо цикл БЕЗУСЛОВНЫЙ. Вот посему for c ОТСУТСТВУЮЩИМ условием есть логично, а while c БЕССМЫСЛЕННЫМ ВЫРАЖЕНИМ условия, есть настораживающий факт.


Тем неменее изрядно часто используется if(0){...} для того что-бы закомментировать кусок исходника. Кому-то это уже ужасным не кажется - типа очередной супертрюк - одним символом комментировать/раскомментировать. Задавлены предупреждения и понеслись писать говнокод.

Гы-гы. Развели мегасрач на пустом месте. Модераторы за прыжок на месте расстреливают, а тут такое... Я их не понимаю

Все сразу отсутствующие аргументы лично у меня вызывают диссонанс. Как и do .. while (0) в дефайнах из-за доисторических компиляторов, выдававших варнинг на голую точку с запятой. Последнее напоминает решение проблемы через одно место.

Константа обязана быть корректным аргументом для опциональной совместимости. Бессмысленность, при желании, можно усмотреть даже в существовании людей. Или себя. И аргументировать это повышением уровня интеллекта/самосознания или сменой точки отсчёта. Вас уже просили использовать терминологию стандарта. У программистов есть законное право использовать любой из разрешённых вариантов.

На самом деле предупреждает не зря. Одно дело 1 << 7 + 16, а сам неоднократно накалывался на word = byte1 << 8 + byte2, хотя точно знаю, что приоритет у сложения выше. И только благодаря этому предупреждению не тратил время на поиски очевидной, но тем не менее пролетающей между глаз ошибки.

По поводу вашего спора о do {} while (0). Единственное место, где это выражение необходимо - подобный функции макрос из более чем одного выражения. Который можно не задумываясь и однообразно вставлять в любое место, где допустим вызов функции, в том числе и в выражение if(cond) macro(); else ... И идите лесом с убеждениями меня в бессмысленности while(0) - он здесь делает именно то, что от него требуется. И я буду его использовать в линейном коде do { if(!func1()) break;... if(!func2()) break; ..... } while(0); потому что это совершенно однозначная конструкция, существенно упрощающая исходник. И мне глубоко фиолетово, что кому-то она эстетически неприятна.

Дело совершенно не в эстетике. В безвыходных случаях можно использовать все. Вот я тоже использую, например для того, что-бы до поры до времени не трогать чужие исходники, например того-же FreeRTOS, где макросов дофига. Только у меня warning на это активизированы и давятся прагмами по месту. А в общем случае сложные макросы-псевдофункции просто не надо использовать - есть механизм заинлайнивания функций. Такой подход безопаснее.
Warnig активизированы всегда по максимуму. Не для себя, а для того, что-бы были в качестве одного из индикаторов какчества попадающих в мои руки чужих исходников.

Горе тому программисту, который написав while(0) думает получить что то иное....

Горе тому, кто не может ни думать (а чего тут думать - трясти надо писать while(1) надо - так все индийские студенты пишут) ни даже читать: http://electronix.ru/forum/index.php?showt...t&p=1361255

Препроцессор тут с визгом притянут за уши. Это не аргумент. Совсем.

А зачем писать на самом деле НЕПОНЯТНОЕ, хотя и "привычная", но бессмысленная конструкция while(1), на которую хоть и некоторые компиляторы, но ругатся (и правильно делают), вместо канонического варианта - цикл БЕЗ проверки условий, прямо для такого случая предусмотренного? Зачем?
Что это вообще - "пока один"? Ну? Тогда-уж агитировали-бы за while( 1 == 1 ) по любому бессмысленная проверка неизменного условия, но хоть какой-то смысл типа "понятнее" можно было притянуть.

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

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

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

1 - это nonzero constant, как раз то, что возникает на пустом месте в for(;;)

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

Согласен, здесь приоритеты не очевидны. Может, действительно, не жалеть скобок...
Надо было сделать приоритеты этих операторов равными.

На while (const) ?

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

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

А где все-же ответ на вопрос http://electronix.ru/forum/index.php?showt...t&p=1361373

?
А по поводу "возникновения" - уже отвечал: http://electronix.ru/forum/index.php?showt...t&p=1361241

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

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


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

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

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

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

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

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


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

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

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

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



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





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



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


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

Как Вы сами заметили, уже перестают. Времена меняются, язык тоже.

Язык, как базовый стандарт, в этом аспекте не меняется - что K&R, что C11 описывают все одинаково. Меняется ТОЛКОВАНИЕ и увеличивается количество говнокода которое коекодеры хотят компилировать чем попало, а авторы компиляторов хотят прежде всего получить новых пользователей и им никчему отталкивать кодеров у которых на "том компиляторе все работало" а этот компилятор "плохой" . Так-что задача прежде всего собрать из под чужого компилятора и помешать (добавление диалектов) чужому собрать свое. Но тем неменее реальной, а не нарочито сделаной несовместимости компиляторов нет уже давно - нормально писаные исходники таскаются у меня по доброй дюжине компиляторов и 8-16-32-64 бит платформам.

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


Это было бы справедливо, если бы какие-нибудь из древних компиляторов считали while(const) ошибкой. Есть такие?

Стандарт языка Cи был и есть лаконичен и многое и было и остается без явного разжовывания.

Я как-бы НИКОГДА не писал по причине нахренненужнсти while(const), так-что когда они были действително старые, то не сталкивался. Ну а потом, когда уже из интернету хлынул поток c таким, то warning были, поскольку всегда все по максимуму поднимаю.

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


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

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

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

А вот такой случай из жизни (специально нашел в интернете, а не сочинил, дабы не выслушивать глупости про уши):
http://www.codeexplain.com/code/253778d0-3...c1-57064dc5a918
Явно БЕССМЫСЛЕННОЕ выражение возникшее в результате ошибки было молча проглочено GCC. А MS предупредил-бы, что ему подозрительно. Вот о озадачился автор, как включить сие предупреждение, ну а ему рассказали что не понимает он своего счастья от отсутствия предупреждения

В операторе for есть 3 выражения, цикл выполняется, если значение 2-го выражения отлично от нуля. В этом ракурсе вовсе неочевидно, что в случае for(;;) проверки условия не будет вообще - будет проверка значения пустого оператора. И уж совсем неочевидно, что значение пустого оператора отлично от нуля.

Очень жаль, что Деннис Ритчи умер, а то Вы могли-бы попробовать "доказать" ему, что он не прав. Но есть рабочая группа по стандарту языка - обраьтиесь туда со своми трактовкам и НОВЕЙШЕЙ терминологией. Мне "доказывать" не надо, поскольку:
Во-первых, мне все понятно в for( ; ; ), поскольку и в русском и английском есть такое слово "безусловно/unconditionally", котороое описывает и данную ситуацию - ОТСУТСТВИЯ условия.
Во-вторых я не могу изменить стандарт.

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

Это Вы себя пытаетесь убедить повторяя одно и то-же? Тогда можете продолжать. Меня не удастся, по причине уже дважды озвученной ранее: http://electronix.ru/forum/index.php?showt...t&p=1361385
И в приведенном прмере http://electronix.ru/forum/index.php?showt...t&p=1361385 отсутствующая "подсказка" оказалось ПРОПУЩЕННОЙ ошибкой. Ошибки тоже никак на качество кода не влияют? Так-что все, с этим закончили. Можете сколь угодно долго в самооправдание продолжать долдонить " Качество кода подсказками не измеряется".