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

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


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

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

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

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


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

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

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

Деление на ремарки и варнинги весьма условное и не у всех компиляторов. У 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(;;) проверки условия не будет вообще - будет проверка значения пустого оператора. И уж совсем неочевидно, что значение пустого оператора отлично от нуля.

Сообщение отредактировал gerber - Aug 30 2015, 09:35

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

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

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

Это как раз случай вопиющей глупости. Что тут вообще можно комментировать? Компилятор не обязан быть нянькой для программиста, не понимающего азов.

Если я, ну, например, пропущу где либо при правке "=" я тоже стану "програмистом не понимающим азов"? Да? В примере человек, зная, как правильно, тупо ошибся.
Так-что пожалуйста хватит о ЧУЖИХ глупостях, подумайте, пожалуй, о своих собственных "ушах".

На то будет выдано совсем иного рода предупреждение, и Вы это прекрасно знаете.


Спасибо, пожалуй, действительно поберегу их от чужих КРИКОВ.

Выдано? А зачем выдано? Может не надо его выдавать? Пусть программист "знающий азы" разбирается без "компилятора не обязаного быть нянькой для программиста".
Так-что уже действительно "поберегите себя" а то Вам тяжело раздваиваться.

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

По вашему же примеру
if (fooType == FOO_TYPE_A || FOO_TYPE_B)
что хотел этой строкой сказать автор? fooTpe равно А или В? тогда где скобки? Почему логический оператор? Написана глупость и плохо написана, но обсуждаем что компилятор пропустил ошибку. А может он за вас и программу должен написать? Советы давать где вы что не так закодили?