Я призадумался сегодня. Вот ведь есть модификатор const. В самих функциях и классах он применяется. А вот в параметрах функции применяется или нет? Я заметил, что не часто.
 Хотя по сути,  если параметр функции не изменяется, то можно было бы и применить. Так?
 Или это не обязательно?

Почему же это. Посмотрите исходники хороших open source проектов. Применение const в параметрах помогает избежать трудновылавливаемых ошибок.
Хотя есть люди, которые имеют совершенно противоположное мнение и считают, что применение const в параметрах это зло.

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

Это сообщение отредактировал(а) math64 - 4.9.2014, 08:23

Наоборот. Применяется. И повсеместно. Если в каких-то исходниках можно добавить const, но его там нет, то это - плохие (или очень старые, как заметил math64).
Ещё один момент - в языке Си (не путать с Си++) до стандарта С99 модификатора const просто не было, А огромное количество исходников написано именно на нём. Они прекрасно (ну... почти) компилируются современными компиляторами Си++, и их просто никто не хочет модифицировать. Работает - и ладно.

Это сообщение отредактировал(а) borisbn - 4.9.2014, 12:56

А ещё немалое количество исходников написано на адской смеси C/C++, в которой вообще что угодно можно увидеть. По сабжу же, конечно, достаточно будет процитировать владыку нашего Мейерса  

и отослать ТСа за подробностамя к фолианту Мейерс - Эффективное использование C++, 3-е изд. (2006).  

Где бы их увидеть...

Я чего спросил. Вот, например, у меня метод:


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

Верно? Получается, что методы "удлинняются"

11 параметров в функции - уже плохо. А вообще - принято простые типы (int, double, etc.) передавать по значению, а объекты (string, datetime, etc.) - по константной ссылке. Т.о. твой метод д.б. таким


и ?
Код пишется один раз, а читается - много.

github, sourceforge

нет. параметры передаются по значению, поэтому ставить перед ними const - тавтология. так что в упомянутой функции fOrderSend const вообще не нужен.
const имеет смысл, только если параметр передается по ссылке или указателю, что бы избежать лишнего копирования. обычно это делается для сложных типов (которые длиннее указателя).  тогда функция превращается в то, что показал borisbn.

Согласен. Я это и хотел отписать. Какой резон писать const перед переменной, которая передаётся по ссылке и модифицируется, а после возвращается по ссылке из функции в вызывающую.

щито?   

Полностью согласен с предыдущим оратором. Ни разу не понял этой фразы

Вы ошибаетесь.

Квалификатор const гарантирует, что имя будет использовано только для чтения.

Это важно не только для читабельности, и оптимизации (древним компиляторам помогало оптимизировать код), но так же является важным требованием для строгих гарантий.

Строгая гарантия - гарантия, что в случае, если процедура зафейлится, данные не будут утеряны:




Если же вы не указываете const у аргумента, значит теоретически вы можете перетереть входной аргумент.

Читатель уже не может закладываться на строгие гарантии кода.
В момент Х нельзя знать наверняка, содержит ли входной аргумент оригинальное значение, или его уже перетерли.


В книжках рекомендуют использовать const по максимуму: везде, где только возможно.

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


От того что вы напишите лишний раз const для аргумента, который является значением - не переломаетесь.

Однако, профит от такой практики налицо: строгие гарантии безопасности, лучше оптимизация, выше читабельность кода.



Это сообщение отредактировал(а) Lukkoye - 8.9.2014, 11:47

и практически тоже:

однако это не касается переменной в вызове, т.к. передается не она сама, а копия, и с точки зрения вызывающего разницы нет.

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

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

Однако, вызывающая сторона стороне рознь.



Формально Sum дает строгие гарантии, потому что всегда работает с копией аргумента. 
В случае аварии мы всегда знаем каким было последнее валидное i, с которой операция прошла успешно.

Однако Sum здесь - лишь часть большого цикла. Лишь один из элементов большой транкзации.
В случае провала функции foo, откатить нужно весь цикл, а не только последнюю неудавшуюся итерацию.

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



Добавлено @ 13:44
Если в каком то частном случае строгие гарантии не нужны, а их обеспечение сопряжено с неоправданными усилиями - тогда конечно не стоит так заморачиваться, и лучше делать так, как проще и удобнее.

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

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




Это сообщение отредактировал(а) Lukkoye - 8.9.2014, 13:45

Эх, const это ещё цветочки. Microsoft учудила сначала это, потом это. Вот это да...