Как влияет на производительность передаю ли я по указателю или по параметру переменную в функцию?
Если я передаю по параметру процессор создает новую переменную и копирует в нее значание, а потом удаляет. 
В случае с указатетем по * или & я работаю только лишь с указателем.

Тогда получается для высокой производительности нужно всегда передавать по указаетлю или по ссылке?

смотря какой тип переменной. если простой, встроенный (double, int и т.п.), то разницы нет. Если это структура из двух полей (например width и height), то разница есть, но настолько мизерная, что ты её не ощутишь. Если же это какой-то здоровый навороченный класс с десятками полей, некоторые из которых являются в свою очередь классами, то, ессно, "выгоднее" передавать такую переменную по ссылке.


Сильно зависит от ситуации, а также от реализации классов, с которыми работаешь.
Ситуация:

если в ф-ции sendDrawDataToAnotherThread указатель на SomeDataToDraw передаётся в другой поток, то этот (другой) поток получит указатель на уже разрушенную область памяти, т.к. drawData был создан на стеке.
В данном случае (создание объекта на стеке) просто необходимо передавать копию этого объекта.

Я для себя, например, установил следующее правило: работая в одном потоке передавать только константные ссылки на объекты (за исключением случаев, когда объект нужно заполнить - тогда неконстантная ссылка). Если же данные передаются между потоками, то чёткого правила нет, т.к. в одном случае есть смысл передавать копию, в другом - указатель на объект, созданный в куче через new, в третьем - shared_pointer... но в любом случае не ссылку.

P.S. Преждевременная оптимизация - источник зла (С) Александреску, кажется.
Прежде чем думать о производительности программы, IMHO нужно озаботиться
1. Грамотностью её архитектуры
2. Написанием понятного и простого кода
3. Отладкой, выявлением ошибок и всех подводных камней
4. Созданием документации по программе

а вот затем уже и производительностью ( в версии 2.0  )

Обратил внимание, что производители браузеров примерно так и делают. В каждой новой версии они работают всё быстрее и быстрее, а архитектура практически не меняется. Там не дураки работают.... (Ишак не в счёт)

Это сообщение отредактировал(а) borisbn - 2.4.2011, 11:00

на стеке создается новая переменная, в нее копируется значение, по выходу она освобождается


очевидно, что в этом случае на стеке создается указатель


классы и структуры - да
а вот для встроенных типов скорее не надо
во-первых выигрыша не будет (указатель все-равно копируется)
во-вторых логика усложнится

Это сообщение отредактировал(а) alexvs11 - 2.4.2011, 11:28

для простых типов (особенно int) лучше по значению..

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

  

поясните..  

boostcoder, зачем писать f( const int& value ), когда можно написать f( int value ) и не боятся, что кто-нибудь сделает ((int&)value) = 100 таки изменив значение переменной

alexvs11, ну а логика тут при чем?

Добавлено через 12 секунд
или о какой вы логике говорите?

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

под логикой понимаю специфицированное поведения

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

если вы пишите:

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

чудеса да и только..

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

Это сообщение отредактировал(а) borisbn - 2.4.2011, 14:03

и они изменяют декларации?  
накой вы тогда их пишите так, что после вас все(всем?) приходится переписывать?

где я это сказал ? откуда Вы это взяли ?

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

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

и называется ли интерфейс после этого интерфейсом, в его стандартном понятии?

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

ээээ... мне даже представить такое в реале не удается...

Это сообщение отредактировал(а) boostcoder - 2.4.2011, 14:10

В идеале, да. Но бываю разные личности. Причем, чем одиознее мозк, тем выше самомнение. Конечно, старший должен учитывать специфику своих подчиненных, но не всегда за всем уследишь. Да и возможный полет мыслей, действительно, представить себе сложно. Так что все должно быть настолько просто, насколько возможно (не противореча назначению, семантике и производительности). В этом смысле int проще чем const int&.


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

речь шла о передачи по указателю (не по ссылке)..

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