Developing.ru

Конструктор класса вызывается при создании любого экземпляра этого класса, а в теле конструктора прописано безусловное создание ещё одного локального экземпляра того же класса, для чего опять будет вызван тот же конструктор. Получается бесконечная рекурсия.. Деструктор класса вызывается при уничтожении любого его экземпляра, а в теле деструктора прописано безусловное создание, а значит и безусловное уничтожение ещё одного локального экземпляра того же класса. В результате бесконечная рекурсия.

... *f(...)
{
...x;
...
return &x;
}

Нельзя возвращать указатели на автоматические локальные переменные, так как после возврата эти переменные не существуют.

... &f(...)
{
...x;
...
return &x;
}

И ссылки на такие переменные тоже возвращать нельзя. По той же причине.

А здесь:

... &f(...)
{
static ... x;
....
return &x;
}

синтаксис локальной переменной использован не по назначению, что может сбивать с толку тех, кто не прочитает целиком тело функции. Если уж переменная фактически глобальна, то так её и объявите.

Ой, а дайте, дайте я добавлю таких же очевидных и общеизвестных советов

Не объявляйте переменную глобальной, если вам нужна локальная.
Не объявляйте переменную локальной, если вам нужна глобальная.
Вообще не объявляйте переменную, если она вам не нужна...ту би континуед.

А ещё сколько этого же в учебниках по С++

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

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

А Вы ожидали где-нибудь увидеть что-то вроде "Не делайте бесконечную рекурсию, потому что получится бесконечная рекурсия"? Так для 99% людей это и так очевидно, Вы просто в эти 99% не попали

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

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

От меня чуть более сложная зарисовка, тоже про конструкторы. Лично встречал такой код в проекте. Кто увидит и опишет суть проблемы будет мною похвален:

Кто увидет и опишет суть проблемы

Очевидно, копирование будет нормально работать, если поля исходного класса не ссылочные. А если ссылочные, то новый класс и rhs будут содержать поля с одинаковыми ссылками. После уничтожения rhs поля нового класса будут указывать на участки памяти, которые более не доступны.