не только msvc.. 
Предполагается что в _условиях_ правильна лишь инициализация, но не присваивание.. 
т.е. если этот код вызовет предупреждение:

то этот вполне легален:


Это сообщение отредактировал(а) mes - 14.7.2010, 09:25

Не обращаю внимания на эту мелочь, пишу так, как с языка слетает (что с чем сравнивать). ИМХО проблема надуманая, но странно, что идею еще никто не довел до идиотизма

и отказу от == в коде.

Это сообщение отредактировал(а) djamshud - 14.7.2010, 09:25

как с языка слетает, зависит от привычки. У всех ( с опытом ) кто написал _слева_, именно так и слетает с языка 

константа справа.
Ошибался только в начале (когда после паскаля пересел на С), сейчас крайне редко (все случаи, что я помню, исправлял тут же). Думаю, потому что компилятор выдает предупреждение. Оно конечно раздражает, когда надо действительно использовать присваивание внутри условия (if (f = fopen(...))... ), но никто не мешает использовать еще одни скобки.

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



чем



Рекомендовано варнингом студии. Первое, что пришло в голову, в while можно по ошибке воткнуть переменную l вместо 1, а как на самом деле?

имхо, из за того что условие безусловное.

semibug, я использую Qt, а там есть для этого forever:

Это не холивар. Дело в том, что VC 6.0 при стандартных настройках оптимизации генерировал разный код.

При использовании while( 1 ) { __asm nop; } компилятор генерировал что то вроде:



А при использовании for( ;; ) { __asm nop; } было что то вроде:



(по памяти)

--
Но сей час проверил на VC 2008 -- там генерируется одинаковый код что для фор, что для ваил:



Так что по сути сей час разницы нету что использовать.
--
Ну это я описал с точки зрения оптимизации. А так сам использую for( ;; ) уже по привычке.

константа справа  

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

Это сообщение отредактировал(а) azesmcar - 19.7.2010, 10:22