47 / 21 / 11
Регистрация: 01.11.2013
Сообщений: 255
|
|
1 | |
Как лучше передавать аргумент в функцию - по ссылке или по указателю?30.01.2016, 20:31. Показов 10517. Ответов 20
Метки нет (Все метки)
Предположим, что нам нужно в функцию передать значение переменной чтобы по окончанию работы функции значение переменной изменилось. Меня интересует, что лучше использовать если мы знаем название переменной, ссылку или указатель? И что будет эффективнее? Мне кажется, что ссылка будет лучше, так как для указателя нужно выделять память чтобы он хранил адрес переменной. Но все используют указателя, а не ссылки.
0
|
30.01.2016, 20:31 | |
Ответы с готовыми решениями:
20
Передача в функцию по ссылке или указателю Передача параметров в функцию по значению, по ссылке или по указателю Зачем при перегрузке инкремента дружественной функцией передавать аргумент по ссылке? Как передать из функции пользователя в главную функцию значения по ссылке и указателю |
634 / 389 / 75
Регистрация: 21.09.2008
Сообщений: 1,330
|
|
30.01.2016, 20:48 | 4 |
maks242, чтобы не "гадать на кофейной гуще", сгенерируйте компилятором ассемблерный листинг и сравните вызовы. Делов-то.
0
|
8971 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
30.01.2016, 20:49 | 5 |
Сообщение было отмечено maks242 как решение
Решение
существует мнение, что ссылки более эффективны,
поскольку имеют больше шансов на оптимизацию. однако, в наши дни это уже не актуально. современные компиляторы прекрасно оптимизируют и ссылки, и указатели. но если в плане компиляторов и можно считать, что разницы нет, то с кодом программистов выползают самые перпендикулярные нюансы. инвариантный, грамотно оформленный код с ссылками более эффективен, нежели с указателями. например, потому что ссылки не нужно проверять на валидность. один лишь этот фактор делает код с ссылками более эффективным. об этом не нужно переживать. если компилятору не доступен контекст использования ссылки, то он реализует её через механизм указателя. с другой стороны, если компилятору доступен контекст использования, то он и указатель сможет оптимизировать так же, как и ссылку. не знаю, кто такие "все". грамотные люди используют ссылки там, где ожидается работа с реальным (валидным) объектом. и указатели там, где ожидается работа с адресом, а объекта может и не быть. "указатели во все поля" - так делают либо совсем зеленые новички, либо сишники, которые так и не осилили плюсы, либо "священаы воены", которые любят кушать свой кактус, либо просто балбесы.
3
|
2549 / 1208 / 358
Регистрация: 30.11.2013
Сообщений: 3,826
|
|
30.01.2016, 20:57 | 6 |
да я такой)))
И да я не использую ссылки т.к. при вызове не понятно будет ли изменён объект, и ссылку не переназначишь если надо изменить поведение в процессе.
0
|
8971 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|||||||||||
30.01.2016, 21:00 | 8 | ||||||||||
может быть вот так вам будет более очевидно?
2
|
2549 / 1208 / 358
Регистрация: 30.11.2013
Сообщений: 3,826
|
||||||
30.01.2016, 21:45 | 9 | |||||
hoggy, вы сейчас о чём?
Я о холливаре где обсуждается
0
|
8971 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||||||||||||||||
30.01.2016, 22:23 | 10 | |||||||||||||||
ссылка в принципе не подходит для случаев,
когда нужно перенацеливаться. это - бессмысленный холивар. http://rextester.com/PYMJNF60861
не зная прототипа, вы не можете с 100% уверенностью сказать, какие гарантии даёт вам функция. но обычно, благодаря читабельным именам, и граммар конст, итак понятно, что сотворит функция с аргументами. ------------------------------------------------------------ существует соглашение о стиле кода, согласно которому, аргументы, которые могут быть модифицированы внутри функций, надлежит передавать по указателям. нотация берет свои корни из языка си, который не умеет ссылки, но хочет модифицировать указатели на языке с++ это выглядит так:
однако, сишка ссылки не умеет, и поэтому, там приходилось делать так:
что бы иметь возможность воздействовать на оригинальный указатель. на сишке просто нет иного способа, что бы поиметь желаемый профит. однако на плюсах все гораздо проще. и здесь такая нотация просто не актуальна.
1
|
2549 / 1208 / 358
Регистрация: 30.11.2013
Сообщений: 3,826
|
|
30.01.2016, 22:53 | 11 |
так и я о чём? Гибкость -)
да они все лишены смысла) а на англ как? не могу загуглить, что за идеалогия такая. Только ваш холиварчик нашёл с Avazart`ом тыц Итого я то и сам использую const T& но есть же ж случаи когда я делаю &name - к своему стыду и малому опыту не могу навести сейчас пример, но он ведь есть же ж)
0
|
8971 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|||||||||||
30.01.2016, 23:34 | 12 | ||||||||||
гибкость ради гибкости не нужна.
гибкость нужна лишь там, где это объективно необходимо:
вопрос лишь в цене, и в целесообразности. если ожидается живой объект - проще и дешевле использовать ссылку. если же нужно будет перенацеливаться, то вам ничего не мешает повесить принимаемые данные на указатель, и менять его потом на что нибудь другое. Добавлено через 2 минуты а хз если вкратце: const во все поля. если объект предназначен только для чтения, то он должен быть const если функция-член не изменяет состояние объекта, а выполняется только в режиме для чтения, то она должна быть const. вроде бы Маерс писал, если не ошибаюсь: "все, что может быть const, должно быть const"
2
|
Модератор
|
|
31.01.2016, 09:34 | 13 |
Он самый. Из книги "Эффективное использование C++ - 55 верных советов" (3-е издание, 2006):
Сообщение от Скотт Мейерс
У Макконнелла в книге "Совершенный код" (10.3. Принципы инициализации переменных):
Сообщение от Стив Макконнелл
0
|
8971 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||||||
31.01.2016, 12:03 | 15 | |||||
идея дает:
+1 к защите от изменений изнутри функции и в то же время: +1 к синтаксическому мусору: http://rextester.com/JWUX61217
идентичного по факту типа только запутывают. о защите от изменений изнутри функции, он как то не упомянул.
0
|
Неэпический
|
|
31.01.2016, 12:11 | 16 |
hoggy, а теперь вдруг, мы решили переместить объект типа example (назовем его obj) в функции foo.
Простой std::move(obj) уже не прокатит, т.к. врядли в example есть констуктор example(const example&&) Соответственно, придется либо менять тип параметра, убирая const, а это приведет к необходимости изменения клиентского кода, а можно требовать у клиента вышеуказанного конструктора, что тоже крайне убого, либо к снятию const у obj, в данном, случае, это, наверное, самое лучшее решение будет. Но тогда возникает вопрос, на кой черт этот const вообще поставили изначально. То есть он нам тупо может мешать в будущем, Вот я к чему
0
|
8971 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
31.01.2016, 12:23 | 17 |
const в прототипе именно для того и существует,
что бы накорню пресекать подобные действия. строгие гарантии, за которыми следит компилятор. строгие гарантии нужны для обеспечения отказоустойчивости системы. но предоставить их может лишь тот функционал, который гарантирует, что в случае каких то поломок, всегда можно откатиться взад. так, словно вызова функции, приведшего к аварии "как бы и не было".
0
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
31.01.2016, 12:49 | 19 |
Croessmah
Мне кажется, хотя я не уверен, что если указать явно на то, что объект константный, то над ним можно проводить естественные для иммутабельных объектов оптимизации. Например, одну и туже inline функцию foo можно будет использовать как для обработки неволатильных объектов внешнего кода, так и для обработки волатильных объектов. Причём в первом случае компилятор имеет возможность "оптимизировать дорогое копирование", а во втором скопировать объект, в отличие от передачи по ссылке, гарантируя неволотильность объекта внутри foo.
0
|
8971 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
31.01.2016, 13:13 | 20 |
ни разу ни случалась.
что впрочем и не удивительно. потому что нет объективных причин передавать крупные объекты по значению. а если понадобится копия - её всегда можно сделать изнутри функции. а для случаев опустошения, которые не имеют легаси с с++03, дизайн специально предусматривает мув-конструкторы, и мув-операторы.
0
|
31.01.2016, 13:13 | |
31.01.2016, 13:13 | |
Помогаю со студенческими работами здесь
20
Что оптимальнее: передавать матрицу как аргумент, или же формировать её внутри функции? Как лучше передавать значения в функцию? Ссылки vs указатели Передача аргументов в функцию по ссылке и указателю Передача параметров в функцию по значению, по ссылке и по указателю Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |