MSDN говрит:
Reference and const member variables must be given a value when initialized or in the constructor.

Почему переменные Reference должны быть всегда инициализированны?
Почему я не могу написть

   Obj& o;

и только потом в дальнейшем присвоить ему объект?

Спасибо.

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

TA>Почему переменные Reference должны быть всегда инициализированны?

Должны же ссылки хоть чем-то кроме синтаксиса от указателей отличаться

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

TA>MSDN говрит:
TA>Reference and const member variables must be given a value when initialized or in the constructor.

TA>Почему переменные Reference должны быть всегда инициализированны?
TA>Почему я не могу написть
TA>

TA>   Obj& o;
TA>

TA>и только потом в дальнейшем присвоить ему объект?

Такова уж природа ссылки, так она задумана. И тут не играет роли, является ли ссылка членом класса или она существует самостоятельно. Основная идея ссылки в том, что она не может существовать в неопределенном состоянии, и не быть связанной ни с каким объектом. Это дает возможность разработчику не делать лишних проверок на валидность ссылки. Кроме того, будучи один раз проинициализирована, ссылка уже не может изменить объект привязки, что опять же, сужает круг необходимых проверок при использовании ссылок. Если такое поведение не подходит, если требуется возможность отложенной инициализации и изменения адресуемого объекта, то для этих целей существуют указатели.

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

TA>MSDN говрит:
TA>Reference and const member variables must be given a value when initialized or in the constructor.

А куда, простите, ссылке ссылаться, и что константе присвоить? Разработчики компилятора правы в данном случае.
Такие типы требуют значений сразу.

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

TA>Почему я не могу написть
TA>

TA>   Obj& o;
TA>

TA>и только потом в дальнейшем присвоить ему объект?

К сказанному вам до меня добавлю также, что ссылка или константа внутри класса это всегда геморрой. У вас выключатся стандартный копирующий конструктор, оператор присваивания, вам придётся контролировать списки инициализации всех конструкторов класса чтобы она там была. Дважды подумайте, прежде чем на такое идти. Хуже пожалуй только голый указатель внутри класса -- с ним вы получаете всё то же самое в неявном виде. Рассмотрите возможность использовать вместо неё умный указатель, контейнер STL или объект по значению, эта возможность почти всегда есть и существенно облегчит вам жизнь в далёкой перспективе.

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

T>... Хуже пожалуй только голый указатель внутри класса -- с ним вы получаете всё то же самое в неявном виде...

Если только вы не создаете собственную умную обертку над голым указателем

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

R>Такова уж природа ссылки, так она задумана. И тут не играет роли, является ли ссылка членом класса или она существует самостоятельно. Основная идея ссылки в том, что она не может существовать в неопределенном состоянии, и не быть связанной ни с каким объектом. Это дает возможность разработчику не делать лишних проверок на валидность ссылки. Кроме того, будучи один раз проинициализирована, ссылка уже не может изменить объект привязки, что опять же, сужает круг необходимых проверок при использовании ссылок. Если такое поведение не подходит, если требуется возможность отложенной инициализации и изменения адресуемого объекта, то для этих целей существуют указатели.

О! Раз пошла такая тема.
У меня недавно возник вопрос. Как в компиляторе реализованы ссылки? Так же как и указатели, только константные?
Может кто ни будь просветить? Или где можно об этом прочесть?

Спасибо.

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

k55>О! Раз пошла такая тема.
k55>У меня недавно возник вопрос. Как в компиляторе реализованы ссылки? Так же как и указатели, только константные?
k55>Может кто ни будь просветить? Или где можно об этом прочесть?

С практической стороны, думаю, в любом более-менее вменяемом компиляторе внутреннее представление ссылки и указателя идентичны. Некоторые несознательные товарищи строят на этом разные грязные хаки. Например, хак, изменяющий объект привязки ссылки:

#include <iostream>

template<typename T>
struct Ref
{
  T& ref;
  Ref (T& ref) : ref(ref) {}
};

int main()
{
  int i1 = 1;
  Ref<int> ref = i1;
  std::cout << ref.ref << std::endl; //Output: 1

  struct Aux { int* ptr; };

  int i2 = 2;  
  reinterpret_cast<Aux&>(ref).ptr = &i2; //Output: 2
  std::cout << ref.ref << std::endl;
}

Если после компиляции эта программа выводит 1 и 2, значит в Вашем компиляторе ссылка и указатель имеют одинаковое внутреннее представление. Но хорошая программа никогда не должна полагаться на это, потому что в стандарте описывается что со ссылкой можно делать, но не как она устроена.

С точки зрения использования, ссылка является как бы вторым именем некоторой переменной. Можно также считать, что ссылка — это некая особенная разновидность указателя, который автоматически разыменовывается при каждом обращении к нему.

Почитать об этом можно в любом учебнике и справочнике по C++. Ну и, конечно же, в стандарте языка.

Tilir:

T>К сказанному вам до меня добавлю также, что ссылка или константа внутри класса это всегда геморрой. У вас выключатся стандартный копирующий конструктор

Ну, здрасьте. Копирующий конструктор вполне может неявно определяться для таких классов:

#include <iostream>

struct X
{
    int &reference;
    int const constant_variable;
};

int main()
{
    int n = 1;
    X x1 = { n, 2 };
    X x2 = x1; // well-formed
    std::cout << x2.reference << std::endl;
    std::cout << x2.constant_variable << std::endl;
}

T>, оператор присваивания

Далеко не всем классам нужно быть CopyAssignable.

T>, вам придётся контролировать списки инициализации всех конструкторов класса чтобы она там была.

Если инициализация ссылки пропущена, то компилятор об этом сообщит.

T>Дважды подумайте, прежде чем на такое идти. Хуже пожалуй только голый указатель внутри класса -- с ним вы получаете всё то же самое в неявном виде. Рассмотрите возможность использовать вместо неё умный указатель, контейнер STL или объект по значению, эта возможность почти всегда есть и существенно облегчит вам жизнь в далёкой перспективе.

А можно пояснить на конкретном примере?

    template<typename Mutex>
    class lock_guard
    {
    private:
        Mutex& m;

        explicit lock_guard(lock_guard&);
        lock_guard& operator=(lock_guard&);
    public:
        explicit lock_guard(Mutex& m_):
            m(m_)
        {
            m.lock();
        }
        lock_guard(Mutex& m_,adopt_lock_t):
            m(m_)
        {}
        ~lock_guard()
        {
            m.unlock();
        }
    };

Чем тут плоха ссылка, и какой умный указатель, контейнер STL или объект по значению является здесь лучшей альтернативой?

TheAteist wrote:

> Почему переменные Reference должны быть всегда инициализированны?

Потому что это тебе не Java.

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

...
T>...Рассмотрите возможность использовать вместо неё умный указатель, контейнер STL или объект по значению, эта возможность почти всегда есть и существенно облегчит вам жизнь в далёкой перспективе.

К сказанному можно добавить Null Object паттерн. Чтобы не проверять постоянно умный указатель и др. на 0.

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

TA>MSDN говрит:
TA>Reference and const member variables must be given a value when initialized or in the constructor.

TA>Почему переменные Reference должны быть всегда инициализированны?
TA>Почему я не могу написть
TA>

TA>   Obj& o;
TA>

TA>и только потом в дальнейшем присвоить ему объект?

TA>Спасибо.


Насколько я помню, сначала было можно так делать.
Можно попробовать какой-нибудь Turbo C++ 1.0

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

T>К сказанному вам до меня добавлю также, что ссылка или константа внутри класса это всегда геморрой. У вас выключатся стандартный копирующий конструктор,
Копирующий конструктор по умолчанию замечательно проинициализирует и ссылки, и константы, так что он не выключается.
Наверное, ты имел в виду конструктор по умолчанию (который без параметров), а не копирующий конструктор, вот он не сгенерируется.

You will always get what you always got
  If you always do  what you always did