опрос чисто познавательный - типо как распространено подобное использование конста

1.


2.


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

я предпочитаю передавать параметры по константной ссылке.

zim22, для большинства целых чисел это лишние затраты
они сами прекрасно в 4 байта влазят (то есть происходит копирование), а так ты копируешь указатель на них, да еще и юзаешь свой i через указатель

буду знать.
но объекты классов удобней передавать через константную ссылку.
пример: 


Это сообщение отредактировал(а) zim22 - 22.4.2009, 12:04

ни то ни другое

пользуюсь, именно для того, чтобы дать понять, что эта переменная не задумывалась для изменения



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

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

Другое дело, что потом лень всё это прописывать ;)

Это сообщение отредактировал(а) SABROG - 22.4.2009, 12:51

да, если этого требует логика программы.

например этот код не представляю без конст:




Правда ?  

Добавлено через 1 минуту и 45 секунд
P.S. так как не встречался с необходимостью 2го случая, голосую только за первый, но предполагаю что и для второго может быть ситуация. 

оно как то не кошерно. 
особенно это   

правда
без оптимизации по крайней мере
потому в бусте и есть функционал а-ля boost::call_traits<T>::param_type

Юзаю обе конструкции.
Причём, для тех кто не знает про вторую:

В объявлении функции можно писать

а потом в реализации

Так что ничего лишнего в интерфейс не выносится

оффтоп
жаль тот, кто за извращения проголосовал, не высказался...


ЗЫ. этот оффтоп, чтоб голосование на первой странице еще подержать 

со ссылками такой фокус не прокатит.

error LNK2019: unresolved external symbol "void __cdecl foo(int &)"

Пользую обе конструкции. Вторую, правда, с int - не в пример реже.
С моей точки зрения, это есть (даже в тривиальных случаях) документирование намерений разработчика об использовании переменных - если переменная по дизайну не должна меняться, то она должна быть константной. В случае, если изменяется дизайн и в соответствии с новым дизайном переменную требуется изменять - квалификатор const можно столь явно же и убрать.

Можно считать этот подход паранойей. 

Cтpaнник, вопрос был именно про нессылки
с ссылками давно все ясно 

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

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

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

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


Это сообщение отредактировал(а) J0ker - 23.4.2009, 16:40

Не верно. Передаём какой-нибудь implicit sharing объект. Не по ссылке. Без конста. Вызываем метод без конст-модификатора. Портятся данные как для копии объекта в функции, так и для самого переданного объекта.


Сигнатура функции - это интерфейс. В любом случае. А так давай - и от прайватов и прочих откажемся.. Девелоперы умные - пускай сами помнят 

Моё мнение (для обоих случаев):
1. Использую часто. Единственное - подобные вещи выношу на начало функции.
2. Если физически (см. начало моего сообщения) вариант без конста отличается от вариант с констом, то тоже использую (если логически мне нужна конст-версия).

естественно верно, т.к. речь исключительно о базовых типах


я и говорю - внутря функции - это нихрена не интерфейс


нет
внутря функции - это нихрена не интерфейс


вы путаете отношения между девелопером и пользователем с отношениями между девелопером и его-же функциональными нарушениями мозговой деятельности

Где в той цитате, на которую я отвечал было об этом сказано? ;) Реьч только о "нессылках".


Так.. ещё раз. Смотрим внимательно историю:



"переданный в функцию аргумент" - т. е. параметр функции, т. е. речь о сигнатуре функции.


Бррр... Что есть пользователь, что есть девелопер? Тот, кто функцию вызывает - девелопер или пользователь? 

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

Ммм... Может я слепой, но где было сказано, что речь о POD-типах?!

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

Добавлено через 4 минуты и 19 секунд
а, дошло 

Добавлено через 6 минут и 23 секунды
как афтар опроса, скажу - вопрос не ограничивался ПОД типами
правда я не учел implicit sharing объектов, потому написал int

ну как-бы здравый смысл


изнутри функции - это не сигнатура - это типы переменных


тот кто вызывает - пользователь

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




т.е. здравый смысл автору чужд
так и запишем

!  Любитель

J0ker, давай будем повежливей!;)

Да, кстати с explicit sharing-ом такое тоже прокатит 


Хорошо. А снаружи? 


Любопытно.. Впрочем ладно - с модификаторами доступа несколько иная ситуация, неудачный я пример привёл. А вот скажем конст - как модификатор метода класса (для классов, меняющих только mutable поля) вы используете?

Это сообщение отредактировал(а) Любитель - 23.4.2009, 22:50

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


Вот только константность параметра частью сигнатуры не является.

естественно
иначе как работать с константным объектом

не-POD типы никто по значению и не передает, если явно не требуется. А потребоваться это может только в одном случае - обьект надо изменять внутри ф-ии, а значит и cons Type не катит. Так, что не рассамытриваем этот вариант 


Интерфейс к чему? Сигнатура это сигнатура, интерфейс может быть у класса, у ф-ии нет интерфейса.

набор сигнатур функций библиотеки/класса доступных для вызова есть интерфейс библиотеки/класса.
сигнатура функции есть интерфейс функции.
  

а если не POD класс имеет семантику значений? о чем собственно речь и шла  

налицо явное не понимание слова интерфейс, интерфейс может быть у объекта с которым человек работает, т.е интерфейс это набор методов\функциональности который пользователь может использовать для взаимодействия с обьектом, с ф-ие пользователь не взаимодействует, он ее использует. Т.е ф-ия может быть частью интерфейса, но сама интерфейсом не является.
Lazin, пример можешь привести?

уже приводил

Lazin, можно


Добавлено через 51 секунду
а дальше делай, что хочешь
нельзя изменить, если


Добавлено через 3 минуты и 2 секунды
хотя reset уже не вызовешь - и то радость 

т.е  по Вашему при процедурном стиле программирования или в функциональном слово "интерфейс" не применимо ?!

во во, и я это заметил   
вот к примеру :
http://ru.wikipedia.org/wiki/%D0%98%D0%BD%...%B5%D0%B9%D1%81

обратите внимание на

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

применимо конечно, вот например в С есть интерфейс работы с файлами, это структура FILE и все ф-ии которые работают с этой структурой и поставляются с ней вместе. Здесь в роли объекта выступает файл.
Только причем тут это, вы тут народу впариваете что сигнатура ф-ии есть ее интерфейс, а это чушь.

Lazin, ок, притворимся, что поста Alek86 вообще не было. Я переписываю твой второй пример на 
и мы имеем то же самое, но с передачей по ссылке. Зачем нам нужен был изврат с передачей по значению?

shared_ptr часто для многопоточных приложений используется
при вызове cfoo при создании другого потока должна быть передача по значению

попрошу поаккуратней с выражениями.


да,(в зависимости от контекста с именем или без)
к примеру в псевдокоде




Это сообщение отредактировал(а) mes - 24.4.2009, 14:49

тогда shared_ptr тут вообще не нужен, здесь логичнее использовать weak_ptr


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

  никакого воздуха : _интерфейс функции_ 

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

нет, Вы не с той стороны смотрите, всецело поглащены правилами грамматики cpp. Взгляните шире.
Интерфейс у функции есть, даже если нет декларации.    
Определение функции в cpp описывает и интерфейс и реализацию функцию.
А вынос деклараций в хидер описывает интерфейс  "библиотеки" (набора функциональности)

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

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

Это сообщение отредактировал(а) mes - 24.4.2009, 15:07

нет не может. Я устал с тобой спорить, читай Саттера до просветления.

Добавлено через 46 секунд

у ф-ии нет и не может быть интерфейса, т.к интерфейс бывает только у объекта. Ф-ия это действие.

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

Опять споры по поводу терминологии...

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

А у устройства может быть интерфейс? Или у класса? а у приложения?


грубо товарищь.

Это сообщение отредактировал(а) azesmcar - 24.4.2009, 15:41

классная аргументация, без комментариев.

все что ты перечислил является объектами.


так пусть он аргументирует, как у action может быть интерфейс ;)

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

я аргументы привел, ты лбом уперся и твердишь одно и тоже заведомо ложное утверждение. Я тебя отослал к классику, могу еще отослать к словарям, поможет ли?

Я тоже об этом..интерфейс немного широкое понятие.

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

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


давайте 


после того, как определимся со словарем  


Не забывайте и о том, что я вижу то же самое 


Это сообщение отредактировал(а) mes - 24.4.2009, 16:26

просвещайся

Нет, и не собираюсь.

!  Любитель

Ребята, давайте жить дружно;) А то какой-то злой холивар уже получается, не характерно это для винграда...

Нет, функция это контракт на действие. И, с точки зрения договора, контракт является объектом и имеет следующие методы взаимодействия :
1. метод вызова реализации ф-ции,  параметры и характеристики которого определяются разработчиком функции.
2. метод взятия адреса.

 



Это сообщение отредактировал(а) mes - 24.4.2009, 17:46

mes, надоело тратить время на словоблудие с тобой, оставайся при своем мнении. Ляпнешь где нибудь в будущем при умных людях, будет стыдно.

стараюсь юзать и ту и другую, и ещё

такую. Может функционала оно не дабавляет, зато вносит ясность в код, что функция (метод) может делать, а что - нет.

Т.е. по Вашему тут на форуме умных нет ?!   


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


Это сообщение отредактировал(а) mes - 24.4.2009, 19:53

vinter, 
http://www.google.com/search?hl=en&rls...n%27s+interface
"A function's interface consists of the function's name, its return type, the number and types of its arguments, and the types of exceptions it may throw."
и т.п.

я пользуюсь и

и
пользуюсь

и пользуюсь 


   Но, иногда забываю. Обычно в спешке забываю.

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

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


считаю странным ибо это то же самое что и int x. Кто-то об этом упомянул, наверняка UnrealMan как знаток стандарта.

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

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

Это сообщение отредактировал(а) Alek86 - 29.4.2009, 07:49

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

  

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

имхо. бред