Возможный дубликат:
В чем разница между передачей по ссылке и передачей по значению?
Я знаю, что заголовок может представлять многие другие ответы на вопросы, я считаю, что мой очень конкретный вопрос не был дан ответ в других темах (я искал, извините, если это дубликат).
Для бизнеса: рассмотрим следующие подписи:
A:
void MyFunction(long int x);
B:
void MyFunction(long int & x);
и следующее использование:
void main()
{
short int y = 0;
MyFunction(y);
...
}
Мой вопрос связан с потреблением памяти параметром в кадре стека памяти MyFunction.
В случае A, параметр передается по значению, означает ли это, что он будет использовать sizeof (short int) байтов?
В случае B параметр передается по ссылке, предполагая, что компилятор реализует его с указателем, означает ли это, что он будет использовать sizeof (pointer_typeбайт — что, вероятно, больше, чем короткий int?
(Однажды мне сказали, что при использовании ссылки она может в любом случае потреблять 64 бита, в зависимости от платформы)
Обратите внимание, что функция получает тип long int, как я хотел бы знать, имеет ли она какой-либо эффект в обоих случаях.
И еще один крошечный вопрос — может ли кто-нибудь опубликовать пример, в котором компилятор НЕ будет реализовывать параметр, переданный по ссылке, используя указатель?
Спасибо,
Асаф.
Ответы обязательно зависят от компилятора, архитектуры, ABI и т.п.
В дальнейшем я предполагаю, что рассматриваемые параметры фактически передаются в стек, а не в регистры (большое предположение!), И агрессивных оптимизаций нет.
В случае A, параметр передается по значению, означает ли это, что он будет использовать sizeof (short int) байтов?
Нет, это будет потреблять sizeof(long int)
байт, так как он будет расширен первым MyFunction()
подпись.
В случае B параметр передается по ссылке, предполагая, что компилятор реализует его с указателем, означает ли это, что он будет использовать sizeof (pointer_type) байтов
Одним словом да. Вы не можете передать short&
где long&
ожидается, поэтому я предполагаю, что вы имели в виду, что вы передаете long&
Вот.
Других решений пока нет …