Попробовал тут в одном проекте поставить четвертый warning level и обнаружил, что Visual Studio 2005 теперь выдает предупреждение о неиспользумых параметрах функции. Есть, например,

Здесь я не использую hPrevInstance, CmdLine, CmdShow. На что повлияют следующие изменения:

кроме как на исчезновение предупреждений и лишних имен в области видимости? Влияет ли это, к примеру, на выделение памяти? Если нет, то зачем предупреждения? 

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

На выделение памяти и поведение программы, уже конечно, не повлияет.
А разве раньше при 4-м уровне не было таких предупреждений? По-моему, и в 6-й студии были.
Предупреждения пытаются предугадать часто совершаемые ошибки... Не знаю, является ли частой ошибкой "объявил переменную, а использовать - забыл"
4-й уровень -  сверх-параноидальный, я использую только третий.

 

Это сообщение отредактировал(а) Earnest - 24.7.2006, 13:58

Извините, я немного не так выразился. Говоря "теперь", я имел в виду "при переходе с третьего (установленного по умолчанию) на четвертый уровень".

Ну а зачем обращать мое внимание на это? Тем более, некоторые люди (например, я) не любят даже предупреждения и стремятся, чтобы их не было. Тогда для этого мне придется делать так:

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

PS Можно, правда, использовать


Добавлено @ 14:04 

В VS2005 в свойствах проекта есть еще пункт "Treat Warnings As Errors". Вот он уж действительно сверх-параноидальный.
 

Это сообщение отредактировал(а) 0x07L - 24.7.2006, 13:58

Сложно сказать, какой логикой руководствовались MS разработчики, да и не суть. Если тебе предупреждение мешает, отключи его прагмой, действительно. Если мешает всегда и везде - поставь прагму в stdafx.h (или другой всегда включаемый заголовок).
В MFC еще применяют такой метод: объявлен макрос UNUSED:

И потом, в теле функции добавляют предложения UNUSED(xxx). Например:

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

Это не только у МС такое есть 

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

Да, об этом я не подумал.

Earnest, спасибо за UNUSED. Буду иметь в виду. Но, наверное, не буду использовать. Не очень он мне нравится, обойдусь пока комментариями. 

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

Но по-моему, в данном случае (неиспользуемые параметры), проще их убрать (оставить только типы). Трудно потом добавить, что ли, если понадобятся? А комментарии /*... */ - жуткая пакость: если надо большой кусок кода временно закомментировать - обругаешься. 

Это сообщение отредактировал(а) Earnest - 24.7.2006, 17:34

Маньяки   

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

Для того чтобы понять, какой UINT что из себя представляет, придется смотреть MSDN. А так

все сразу ясно.

Кстати, почему комментарии /* */ не могут быть вложенными? Доводы типа "потому что это стандарт С" не принимаются    

Почему не могут, могут (кажется, у старого досовского борланда была такая опция). Но у Visual C -вроде нет. Наверное, есть какие-то проблемы с лексическим разбором. У С++ их и так полно, так что зачем еще усложнять из-за нестандартной ерунды. 
Для меня довод "придется смотреть в MSDN" смешно звучит: чтобы найти параметры обработчика в MSDN требуется ненамного больше времени, чем на стирание комментариев  .
Тем более, никто не мешает оставить имена параметров в объявлении функции.  

Да, точно.

Добавлено @ 07:20 
У Кернигана-Ритчи написано "Комментарии не вкладываются друг в друга". Не могу. к сожалению, сказать, какого года книга.