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

Например:

bool bLalamba = pEnga->InternalLalamba.LalambaMember;
...
Foo(bLalamba);
Bar(bLalamba);
return bLalamba;

С выведением типов это немножко красивее:

var lalamba = enga.InternalLalamba.LalambaMember;
...
Foo(lalamba);
Bar(lalamba);
return lalamba;

Созрели вопросы: что эффективнее в современных компиляторах — заводить переменную на стеке или несколько раз находить адрес? Кэшируется ли для этого адрес? Есть ли языки, где кроме var'а доступен какой-нибудь alias (если бы не глобальность плюсовых макросов, они бы сгодились)?

Здравствуйте, SV., Вы писали:

SV.>Созрели вопросы: что эффективнее в современных компиляторах — заводить переменную на стеке или несколько раз находить адрес? Кэшируется ли для этого адрес?

VC++ в релизе выкинет, скорее всего, переменную на стеке и сохранит в регистре ее значение, равно как найдет одинаковые выражения для адреса и вычислят один раз. Он и не такое умеет.

Здравствуйте, SV., Вы писали:
SV.>Созрели вопросы: что эффективнее в современных компиляторах — заводить переменную на стеке или несколько раз находить адрес? Кэшируется ли для этого адрес? Есть ли языки, где кроме var'а доступен какой-нибудь alias (если бы не глобальность плюсовых макросов, они бы сгодились)?
По идее такая оптимизаця есть, называется common subexpresion elimination (кажется), но наверняка имеет границы применимости. Мешать ей должны, например, синхронизация, volatile-переменные, свойства с хитрыми геттерами-сеттерами.

Здравствуйте, SV., Вы писали:

SV.>Созрели вопросы: что эффективнее в современных компиляторах — заводить переменную на стеке или несколько раз находить адрес? Кэшируется ли для этого адрес? Есть ли языки, где кроме var'а доступен какой-нибудь alias (если бы не глобальность плюсовых макросов, они бы сгодились)?

Обычная ссылка в C++ и есть такой alias.

Здравствуйте, SV., Вы писали:

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

А по-моему это bad smell, ведь даже однократное использование "многоэтажной" конструкции противоречит закону Деметры, но он не абсолют, безусловно

А что вызвало улыбку ? Я тест сейчас не делал, но зная его поведение...

Здравствуйте, SV., Вы писали:

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

SV.>Например:

SV.>

SV.>bool bLalamba = pEnga->InternalLalamba.LalambaMember;
SV.>...
SV.>Foo(bLalamba);
SV.>Bar(bLalamba);
SV.>return bLalamba;
SV.>

SV.>Созрели вопросы: что эффективнее в современных компиляторах — заводить переменную на стеке или несколько раз находить адрес? Кэшируется ли для этого адрес? Есть ли языки, где кроме var'а доступен какой-нибудь alias (если бы не глобальность плюсовых макросов, они бы сгодились)?

* С точки зрения скорости вынос любого значения выражения в переменную будет как минимум не медленнее нежели повторные вызовы этого выражения. В лучшем случае компилятор устранит общие подвыражения и получит код аналогичный тому что получается при введении переменных. Но любые оптимизации допустимы не всегда. Скажем, если InternalLalamba или LalambaMember — это свойство, то оптимизация может и не быть осуществлена. Так что можно смело ответить, что введение переменной эффективно или по крайней мере не менее эффективно.
* С точки зрения удобочитаемости кода могут быть разночтения. Когда-то удобно использовать два раза одно и то же выражение. Где-то удобнее ввести переменную.
* Код странный. Везде маячит Lalamba, но при этом вроде как получается булево значение.

Здравствуйте, SV., Вы писали:

SV.>Созрели вопросы: что эффективнее в современных компиляторах — заводить переменную на стеке или несколько раз находить адрес? Кэшируется ли для этого адрес?

Мне доводилось писать такой код:

bool const bLalamba = pEnga->InternalLalamba.LalambaMember;
...
Foo(bLalamba);
Bar(bLalamba);
return bLalamba;

иначе компилятор делал повторные вычисления даже встроенного operator->() а не только user-defined.

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

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