Я призадумался сегодня. Вот ведь есть модификатор 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 учудила сначала это, потом это. Вот это да...

Lukkoye, ход вашей мысли понятен и возражений по сути ситуаций, выстреливающих в ногу, не вызывает. но пример ваш аналогичен

и имхо к константности аргумента функции не относится.
что касается const вообще - да, чем меньше переменных, тем меньше ошибок.


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

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

Задача квалификатора не просто улучшать читабельность лучше передавая намерения автора кода.
Его главная задача - предостеречь от ничайных ошибок.

Так например, передав аргумент по значению, как константный, вы получаете 100% гарантию от компилятора, что никто ничайно не перетрет его.

Вы конечно можете дать себе торжественную клятву, что никогда не будете перетирать аргумент. И там где надо - обязательно сделаете дополнительную копию.
Но это - человеческий фактор. Только компилятор может дать вам 100% гарантии.

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


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

что бы удовлетворить все стороны, не используем const в прототипе, но используем в реализации http://ideone.com/KKjcJa


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

Прототип вводит в заблуждение.

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

Не дает индульгенцию на _г_о_в_н_о_код.

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


К тому же так писать банально не удобно.
Удобно написать прототип, а потом скопипастить его для реализации, и не тратить время на коверканье нормального кода превращая его в УГ.


Это сообщение отредактировал(а) Lukkoye - 9.9.2014, 22:55

Нет, не так. Если в заблужление что и вводит, то определение, а не объявление функции.  

Вот, посмотрите на объявление функции:

Передаём же по значению, так? Значит, фактический параметр скопируется в формальный при передаче. И, как следствие, фактический параметр измениться не может. Потому что по значению передаём, а не по ссылке.
Никаких заблуждений же! Всё так и будет независимо от наличия const в последующем определении функции.

А вот когда посмотрим на то, как функция реализована, увидим там const

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

Что даёт неизменность формального параметра? Ну, анализировать функцию вроде как проще, так как на такие параметры можно почти не обращать внимания. Но я сомневаюсь в полезности. Всё-таки постоянство формального параметра - детали реализации и выносить их в интерфейс (то есть уже в объявлении писать const) не стоит. И уж, конечно, не стоит иметь разногласия между интерфейсом и реализацией (как в примере у baldina).

Мейрса уже цитировал, надо бы и Саттера что-ли.   

В вольном переводе


Это сообщение отредактировал(а) kemiisto - 9.9.2014, 23:22

Не принципиально.




Измениться может переданный аргумент.

Мне как то не хочется по второму кругу начинать тоже самое. Читайте предысторию сообщениями раннее.

К тому же:


Прототип замалчивает свои намерения: то ли он собирается перетирать аргумент. Толи писал г_о_в_н_о_кодер.

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

С аргументами-по-значению не так критично, но аналогия та же самая.

Добавлено @ 00:46


О пользе я уже написал.

Насчет заблуждений - любопытно узнать, какие тут могут быть заблуждения?

Вы видите прототип:



А теперь расскажите мне, какие заблуждения у вас могут возникнуть при чтении этого кода?

Саттер  (это ведь он, если не ошибаюсь, писал, что не осилил смысла протектед-наследования? ) меня разочаровывает.

Добавлено через 9 минут и 48 секунд


Что такое "формальный параметр" ?

Это сообщение отредактировал(а) Lukkoye - 10.9.2014, 00:51

Так смысл в том что вызывающей стороне все равно что случится с аргументом внутри функции, а вообще, что я объясняю


Мне кажется это вас в большей степени касается.

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

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

Lukkoye, у меня для Вас плохие новости: Вы не понимаете механизма передачи параметра функции по значению. Ещё раз для Вас повторю: при передаче по значению фактический параметр копируется в формальный, и далее, какие-бы изменения с формальным параметром не произошли, на фактическом параметре они никак не отразяться.


И этот юзернейм критикует Саттера?!  В объявлении функции фигурируют формальные параметры, а передаются в неё в клиентском коде фактические. То есть, в объявлении, скажем,

x - формальный параметр, а при вызове такой функции

a - фактический параметр.

И ещё раз, уже на этом конкретном примере: значение фактического параметра a, передающегося по значению, поменяться ну никак не может, так как при вызове функции оно будет скопировано в формальный параметр x. Значение формального параметра x при этом может измениться, но на вызывающей стороне это никак не скажеться. Ничего Вы там не перетрёте, не болтайте ерундой.

Добавлено через 1 минуту и 3 секунды

Ему уже как-бы 2 страницы пытаются это объяснить. 

const в java соответсвует final.
Если параметр объявлен final, анонимный класс, создаваемый в методе, имеет к нему доступ:

T.o. лишние final могут быть вредны с точки зрения обнаружения ошибок в коде.
Вероятно подобные примеры можно найти в C++ (с учётом наличия лямбда выражений, шаблонов и т.п.)

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

Это сообщение отредактировал(а) kemiisto - 10.9.2014, 10:38

У меня тоже для вас плохие новости - вы невнимательный. Вы не читали предысторию.

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



Ясно. Спасибо.

Возвращаясь к вашей цитате:


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

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



Это если только в стране фей.

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





Это сообщение отредактировал(а) Lukkoye - 10.9.2014, 18:15

Lukkoye, ну, давайте попробуем разложить всё по полочкам. Итак, вот ключевая цитата из Вашего первого(?) сообщения в этой теме.

За оптимизации в древних компиляторах ничего не скажу, но остальное - не верно. И вот почему.

Полочка №1

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

Полочка №2

Крайне желательно чтобы интерфейс и реализация соответствовали друг другу. В случае функции это означает, что список формальных параметров в объявление функции и её определени должны совпадать. Вплоть до квалификаторов. Поэтому вариант, где в объявлении нет квалификатора const, а в определении есть, отметаем сразу.

Полочка №3

Теперь мы приходим к двум вариантам функции, показанным ниже, в которых в первой строчке стоит объявление функции, а во второй - её определение.





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





Даёт ли первый вариант какие-либо дополнительные гарантии? Нет, никаких. Фактический параметр в обоих вариантах передаётся по значению, а значит будет скопирован при передаче и изменений в ходе выполнения функции не притерпит. Единтсвенное, что помимо этого сообщает функция в первом варианте, так это то, что и формальный параметр в ходе её выполнения изменений тоже не притерпит. НО! Это деталь реализации, которая клиентскому коду вообще знать незачем. 


Ещё раз повторю, Вы ошибаетесь. Прототип своих намерений не замалчивает. Фактический аргумент передаётся по значению, и во время выполнения функции его значение не измениться.

Это сообщение отредактировал(а) kemiisto - 10.9.2014, 19:21

Ещё раз повторяю - только в стране сказочных фей.

Меня не очень интересует "точка зрения только клиента". 

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

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

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

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

Добавлено @ 20:18


Я хочу что бы вы прочитали текст. И сказали мне, какие мысли вкладывал программист в эти строки:



Я приведу вам пример:

функция baz:
Что делает - очно не ясно. Но судя по наименованию (foo/bar/baz/etc) - просто маленький демонстрационный пример.
Если автор не г_о_в_н_о_кодер, значит индекс с которым она работает - реально может быть отрицательным числом. 
Функция может перетереть свой формальный параметр, а значит не дает никаких строгих гарантий.

Теперь ваша очередь. 
Вам нужно просто рассказать о том, что по вашему хотел сделать программист.

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

Программист хотел доказать свою точку зрения 3мя демонстраивными функциями, не понимая, что спор о совершенно разных вещях. Его породило ваше высказывание:

после которого уже 2 страницы идет обсуждение того, что эта точка зрения не верна (вы же сами указали "со стороны клиента").

Стоило вам написать что то вроде "мне нравится использовать конст как программисто, и считаю, что это делает поддержку большого проекта более понятным и само-документируемым хоть и нарушает принцыпы инкапсуляции, ИМХО" и ничего такого бы небыло.

За ссылки и указатели говорить не буду, так как речь не о них. Речь только о передаче по константному значению.

И гляда на функцию baz, объявленную следующим образом,

я могу заключить, что при вызове такой функции в моём клиентском коде как-нибудь так

фактический параметр i передаcтся по значению, т.е. значение фактического параметра i будет скопировано в значение формального параметра index. Это гарантирует мне, что значение фактического параметра i во время вызова baz() не изменится. И если мне эта гарантия по какой-то причине важна, то у меня в голове сразу складывается следующая картина {предусловие} команда {постусловие}:

Значение i до и после вызова baz(i) одинаковы, или, иными словами, i является инвариантом данной функции.


Да какого, простите, Вам вообще дела до формального параметра? Каких-таких гарантий мне не даёт функция без index, объявленного как const? Что с const, что без него строго гарантированно

И баста!

Конечно, на уровне реализации const даёт нам инвариантность формального параметра внутри самой функции

В принципе я могу понять, зачем это нужно. НО! В интерфейсе const для pass-by-value параметров бессмысленен, так как никаких дополнительных гарантий на уровне интерфейса не даёт. Остаётся только вариант, где в интерфейсе квалификатор const опущен, а в реализации он в наличии, если уж Вам так нужно гарантировать неизменность формального параметра. Но мне такой вариант не нравится из-за несоответствия объявления функции её определению (Полочка №2 из предыдущего сообщения).

Это сообщение отредактировал(а) kemiisto - 10.9.2014, 21:21

Не всегда возможно, потому что не нужно

почему же тогда и const не использовать лишь в одном месте? 

Это сообщение отредактировал(а) sQu1rr - 10.9.2014, 21:50

Дану? Интересно, каким же образом?




Значит эксперимент не состоялся.



Вы не внимательны.
Я уже писал выше - сопровождение кода.

Это значит не только использовать - но и дорабатывать. В том числе за другими. В том числе другие будут дорабатывать после меня.

Самодокументируемость + гарантии от компилятора, что никто ничайно не напортачит.

 

Раз Вы настаиваете на использовании const, то должны требовоать const и с указателями:

Такое компилятор вроде тоже сожрёт (не проверял), хотя смысла особого нет:

А вообще Ваш спор бессмысленен,  аргументы строн понятны, разве что кто-то найдёт пример вредности такого использования const в С++.

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

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

Потребовалась возможность менять count:

Верно.
Я так и делаю.

Более того: квалификатор const контекстно зависимый.
Есть ситуации, когда он нужен лишь программисту (и компилятор сделает доп. проверки)

А есть ситуации,когда компилятору критично, квалифицировано ли имя const ?


Я спрашивал ребят на собеседовании: прочтите вслух этот прототип:



Многие, очень многие ребята говорили: функция foo, которая ничего не возвращает, в качестве аргумента принимает константную ссылку.

Это не верно. На языке с++ у ссылок вообще нет квалификатора. 



Результат - ноль.

Если вы попробуете его сделать на шаблонах, то CL (компилятор вижал студии) сделает предупреждение - квалификатор ссылок будет проигнорирован и вы получите мутабельную ссылку.
Компилятор gcc сделает тоже самое, только не сделает предупреждение.

Ну так вот, если вы сделаете:



То в качестве результата, вы увидите 1.

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


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

Мне это видится настолько простым, что мне кажется - ну я просто повторяюсь, а добавить нечего.


Мне очень жаль, что господа влезли в этот диалог, предварительно не прочитав мой диалог с господином Baldina

Добавлено @ 17:03


Противоречит здравому смыслу.

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


Найдите. Если сможете. Только их нет.

Добавлено @ 17:07


Так вы проверьте, а потом уже говорите.

Я проверял - квалификатор будет полностью проигнорирован. (cl)

Это сообщение отредактировал(а) Lukkoye - 12.9.2014, 17:09

Не понимаете шуток и намека, как бы пора закруглится (не лично вам, а всем обсуждающим), так как холивар на тему кому как нравится писать код ни к чему хорошему никогда не приводил.
ЗЫ может и не так понял, и мр. math64 действительно считает, что нужно использовать константы с дефолтными параметрами