История изменений
Исправление hatred, (текущая версия) :
само отвалится в нужных местах
Почему оно отваливается там? Может такая необходимость возникнуть в пользовательском классе? А применение ссылки лишь инструмент, ровно как и явное удаление методов.
куча говна
«слова не мальчика, но мужа!»
«Note that using a reference member is almost always wrong»
«almost always wrong»
core guidelines
к ним приложили руки пусть и грамотные люди, но в большей части те же, кто пилил gsl, тот же Саттер (раньше как раз в MS работал). Так что догматично я их тоже не воспринимаю. Как хорошие рекомендации в общем, особенно, если нет понимания механизмов - очень даже. Но слепо следовать всегда - простите.
По ссылкам там не дано разъяснения и раньше в этой фразе фигурировала ещё и отсылка к auto_ptr. Если проблемы последнего обсосали везде, где только можно и ровно по той же причине задепрекйтили, то по ссылке - туман. Я вижу ровно две причины, по которой имеет смысл отказываться:
- Класс не владеет ресурсом - опасность висячей ссылки. Невладеющий указатель тут не спасёт. И ссылка здесь воспринимается как конракт на уровне языка дающий гарантии пользователю: объект живёт, пока твой класс живёт, он точно не nullptr и без дополнительный аннотаций, типа not_null.
- Отваливается копирование и конструктор по умолчанию. Но это далеко не всегда проблема. И иногда и желаемое поведение.
Ну и от foo& _member в плане исчезновения operator= проблема ровно такая же, как от const foo _member. И развивая твою отсылку на Note, есть более детальное правило:
Но тут уже более конкретно: «in a copyable or movable type». Ну а если им нет необходимости такими быть?
Да, Страуструп предложил развернуть этот нотайс до правила, на что Саттер предложил уточнить вышеупомянутый C.12, но за 4 года так и не сподобились: видать очень нужно и проблема очень острая.
Ещё есть и такая дискуссия конкретно по этому нотайсу и вот эта позиция точно ложится на мои высказывания выше. Вообще, там есть и про std::reference_wrapper и чисто косметические неудобства типа вызова .get() на нём, но всё сводится к акценту на almost и пожелания конкретики. А общая канва: под задачу инструмент. Дискуссии 5 лет как, а метры не удосужились конкретики привести.
hobbit, прости, что засираем тему :))))
Исходная версия hatred, :
само отвалится в нужных местах
Почему оно отваливается там? Может такая необходимость возникнуть в пользовательском классе? А применение ссылки лишь инструмент, ровно как и явное удаление методов.
куча говна
«слова не мальчика, но мужа!»
«Note that using a reference member is almost always wrong»
«almost always wrong»
core guidelines
к ним приложили руки пусть и грамотные люди, но в большей части те же, кто пилил gsl, тот же Саттер (раньше как раз в MS работал). Так что догматично я их тоже не воспринимаю. Как хорошие рекомендации в общем, особенно, если нет понимания механизмов - очень даже. Но слепо следовать всегда - простите.
По ссылкам там не дано разъяснения и раньше в этой фразе фигурировала ещё и отсылка к auto_ptr. Если проблемы последнего обсосали везде, где только можно и ровно по той же причине задепрекйтили, то по ссылке - туман. Я вижу ровно две причины, по которой имеет смысл отказываться:
- Класс не владеет ресурсом - опасность висячей ссылки. Невладеющий указатель тут не спасёт. И ссылка здесь воспринимается как конракт на уровне языка дающий гарантии пользователю: объект живёт, пока твой класс живёт, он точно не nullptr и без дополнительный аннотаций, типа not_null.
- Отваливается копирование и конструктор по умолчанию. Но это далеко не всегда проблема. И иногда и желаемое поведение.
Ну и от foo& _member в плане исчезновения operator= проблема ровно такая же, как от const foo _member. И развивая твою отсылку на Note, есть более детальное правило:
Но тут уже более конкретно: «in a copyable or movable type». Ну а если им нет необходимости такими быть?
Да, Страуструп предложил развернуть этот нотайс до правила, на что Саттер предложил уточнить вышеупомянутый C.12, но за 4 года так и не сподобились: видать очень нужно и проблема очень острая.
Ещё есть и такая дискуссия конкретно по этому нотайсу и вот эта позиция точно ложится на мои высказывания выше. Вообще, там есть и про std::reference_wrapper и чисто косметические неудобства типа вызова .get() на нём, но всё сводится к акценту на almost и пожелания конкретики. А общая канва: под задачу инструмент. Дискуссии 5 лет как, а метры не удосужились конкретики привести.