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