Компилятор не ругается, но у меня есть сомнения в правильности подобной конструкции.
Можно так писать?

class A
{
  private:
   X x;
   Y y;

  public:
  class A ():
     y(x) //У y внутри ссылка на x, которая данным вызовом будет прониициализирована
  {}
};

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

_>Компилятор не ругается, но у меня есть сомнения в правильности подобной конструкции.

Если объявления X и Y переставить местами, то компилятор должен обидеться.

_>Можно так писать?

data members defined in the class are initialized in the order in which they appear in the class declaration

Можно. Другое дело, что иногда так писать не стоит, но все от ситуации зависит.

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

_>>Компилятор не ругается, но у меня есть сомнения в правильности подобной конструкции.

L>Если объявления X и Y переставить местами, то компилятор должен обидеться.

Не должен. В лучшем случае, ворнинг покажет. А в худшем молча скомпилирует в неопределённое поведение.

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

_>Компилятор не ругается, но у меня есть сомнения в правильности подобной конструкции.
_>Можно так писать?

_>

_>class A
_>{
_>  private:
_>   X x;
_>   Y y;

_>  public:
_>  class A ():
_>     y(x) //У y внутри ссылка на x, которая данным вызовом будет прониициализирована
_>  {}
_>};
_>

Писать так вполне можно: что переменная x, что переменная y создаются и уничтожаются вместе, ссылка на x будет валидна на протяжении всей жизни переменной y. Тут главное не забывать что инициализация переменных класса происходит в порядке их объявления в описании класса, удаление соответственно в обратном порядке.

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

L>>Если объявления X и Y переставить местами, то компилятор должен обидеться.

C>Не должен. В лучшем случае, ворнинг покажет. А в худшем молча скомпилирует в неопределённое поведение.

Там будет ссылка на неинициализированную переменную. Может выругаться как боцман.

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

_>Компилятор не ругается, но у меня есть сомнения в правильности подобной конструкции.
_>Можно так писать?

если убрать лишнее слово class, то можно
просто надо помнить о порядке инициализации мемберов класса. в вашем случае сначала будет создан x, затем его уже можно использовать при создании y

Спасибо всем ответившим. Всё понятно.
Главное, в правильном порядке расположить объявления мемберов( а, кстати, не порядок в списке инициализации!!!).
Вроде, действительно ничего криминального.

se_sss:

_>Главное, в правильном порядке расположить объявления мемберов( а, кстати, не порядок в списке инициализации!!!).

Если в рамках инициализации y ты только формируешь ссылку на x и не пытаешься через неё получить доступ к объекту, то от порядка объявления x и y корректность приведённой инициализации не зависит.

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

M>se_sss:

_>>Главное, в правильном порядке расположить объявления мемберов( а, кстати, не порядок в списке инициализации!!!).

M>Если в рамках инициализации y ты только формируешь ссылку на x и не пытаешься через неё получить доступ к объекту, то от порядка объявления x и y корректность приведённой инициализации не зависит.

С практической точки зрения согласен.
А вот с теоретической — не уверен. Объекта же ещё нет, т.е. и ссылку на него брать заранее как-то нехорошо.

se_sss:

M>>Если в рамках инициализации y ты только формируешь ссылку на x и не пытаешься через неё получить доступ к объекту, то от порядка объявления x и y корректность приведённой инициализации не зависит.

_>С практической точки зрения согласен.
_>А вот с теоретической — не уверен.

В теории "A reference shall be initialized to refer to a valid object or function", однако ж определение понятия "valid object" в стандарте отсутствует, так что никому до этого ограничения нет дела. Данную формулировку давно уже собираются убрать (см. issue 453), но всё никак не уберут из-за того, что рассмотрению этой проблемы отведён самый низкий приоритет.

_>Объекта же ещё нет, т.е. и ссылку на него брать заранее как-то нехорошо.

Формировать указатель на него можно совершенно легально. Запрещать то же самое для ссылок нет никаких оснований.

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

M>Формировать указатель на него можно совершенно легально. Запрещать то же самое для ссылок нет никаких оснований.

О! Я что-то я раньше не думал про это в таком ключе, и всегда юзал указатели просто!
А ведь уже сейчас можно обойти эту хреновину через *&

struct B { int b; };
struct A { 
    A( B& rB ) : b(rB.b) {}

    int& b;
};

class C {
    A a;
    B b;
    C() : a( *&b ) {}
};

Компилируется и работает!!!

Erop:

E>А ведь уже сейчас можно обойти эту хреновину через *&

Для чего тут *&?

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

M>Для чего тут *&?

Для подавления варнинга

Здравствуйте, Erop, Вы писали:
E>Для подавления варнинга

Плохому учите.

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

MOP>Плохому учите.
Что не так? Это же просто баг в стандарте.

Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gegMOPO4, Вы писали:
MOP>>Плохому учите.
E>Что не так? Это же просто баг в стандарте.

Нехорошо использовать баги стандарта.

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

E>>Что не так? Это же просто баг в стандарте.

MOP>Нехорошо использовать баги стандарта.

В смысле? Что занчит "использовать"? Это просто обход баги в стандарте...