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

I>В следующем примере ссылку надо указателем заменить?:

Тут это может быть немного неудобно, если внутри метода writer::write много пользуются операторами для вывода в поток.
Но если бы был указатель, то это точно было бы по крайней мере не хуже

I>

I>    class writer {
I>        ostream& out_;
I>    public:
I>        explicit writer(ostream& out) : out_(out) {}
I>        void write(. . .);
I>    }
I>    . . .
I>    writer w(cout);
I>    . . .
I>    w.write(. . .);
I>

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

E>Тут это может быть немного неудобно, если внутри метода writer::write много пользуются операторами для вывода в поток.
E>Но если бы был указатель, то это точно было бы по крайней мере не хуже

Так "крайней мере не хуже" или все-таки "немного неудобно"?

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

АЕ>Подскажите, пожалуйста, что предпочесть, ссылку или указатель?

Когда-то ссылку, когда-то указатель, а когда-то умный указатель.
Одного рецепта на все случаи жизни нету.
В каждом конкретном случае можно дать совет и даже как-то его обосновать.

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

I>Так "крайней мере не хуже" или все-таки "немного неудобно"?

О чём именно речь? О хранении поля или о параметре конструктора?..

Если речь о поле, то делаешь приватный метод, который вернёт нужную ссылку + может и что-нибудь проверить ещё или ещё что-то сделать...

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

E>Если речь о поле, то делаешь приватный метод, который вернёт нужную ссылку + может и что-нибудь проверить ещё или ещё что-то сделать...

А где тут глубокий смысл использования указателя вместо ссылки?

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

    class writer {
        ostream& out_;
    public:
        explicit writer(ostream& out) : out_(out) {}
        void write(. . .);
    }
    . . .
    writer w(cout);
    . . .
    w.write(. . .);

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

I>А где тут глубокий смысл использования указателя вместо ссылки?
Ну поле может быть любым умным или не очень умным указателем...

I>Напомню, ты предложил по умолчанию использовать умные указатели, и только если есть веские причины, то указатели обычные. Ссылкам места вообще не оставил,
В качестве полей!

I>вот я и привел пример со ссылкой, и спрашиваю, что мы выиграем, если заменим ссылку на указатель в следующем примере?:

I>

I>    class writer {
I>        ostream& out_;
I>    public:
I>        explicit writer(ostream& out) : out_(out) {}
I>        void write(. . .);
I>    }
I>    . . .
I>    writer w(cout);
I>    . . .
I>    w.write(. . .);
I>

1) Мне не нравится в этом примере то, что требуется чтобы либо writer был автоматическим объектом, либо аргумент его конструктора должен быть статическим объектом, либо надо как-то ещё гарантировать, что writer переживёт свой поток вывода.

При этом в некоторых компиляторах, параметр может указывать вообще на временный объект!
Так что чревато это ошибками.
Это что касается параметра конструктора. Лично мне вариант с указателем на поток, передаваемым в конструктор, кажется намного более надёжным, хотя и более кондовым, конечно.

Что касается поля, то, например, мы выиграем возможность в любой момент перейти к shared_ptr, скажем, без изенений в остальном коде writer...

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

E>Что касается поля, то, например, мы выиграем возможность в любой момент перейти к shared_ptr, скажем, без изенений в остальном коде writer...

Согласен, это какой-никакой аргумент(ик). Для меня впрочем недостаточный.

PS. Тема обсуждения только про поле и есть, про параметр только ты и пишешь.

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

I>Согласен, это какой-никакой аргумент(ик). Для меня впрочем недостаточный.
Ну я могу ещё иначе сказать, часто бывает так, что если хочется написать член-ссыдку, то на самом деле стоит ещё что-то где-то подправить, чотбы не хотелось

I>PS. Тема обсуждения только про поле и есть, про параметр только ты и пишешь.

В класс передается по ссылке или указателю некий объект(например файл), и затем ссылка или указатель сохраняется внутри, как член данных. И класс затем будет этот объект изменять(например записывать данные в файл). Объект передается в конструкторе, так что его можно передавать и хранить как по ссылке так и по указателю. В первом приближении вроде корректно работает и тот и тот вариант.

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

Я всё-таки придерживаюсь теории, что при программировании мы про все ссылки должны предполагать, что они могут ссылаться на автоматический/временный объект. В частности сохранять в полях указатель на переданный по ссылке объект нехорошо.

Хот вот твой writer, например, как бы предполагает, что он сам должен быть автоматическим и его аргумент или статическим или автоматическим. Но это всё хорошо работает только до тех пор, пока ты не начнёшь как-то хитро своими писателями манипулировать (прихранивать там, или ещё что-то делать). Начнёшь манипулировать -- получишь нехилый шанс нарваться. Если не при разработке, то про поддержке кода...

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

E>Ну я могу ещё иначе сказать, часто бывает так, что если хочется написать член-ссыдку, то на самом деле стоит ещё что-то где-то подправить, чотбы не хотелось

Конкретный пример у тебя есть. Подправь.

E>Хот вот твой writer, например, как бы предполагает, что он сам должен быть автоматическим и его аргумент или статическим или автоматическим. Но это всё хорошо работает только до тех пор, пока ты не начнёшь как-то хитро своими писателями манипулировать (прихранивать там, или ещё что-то делать). Начнёшь манипулировать -- получишь нехилый шанс нарваться. Если не при разработке, то про поддержке кода...

Пока-что я понял, что можно нарваться используя ссылку в качестве параметра конструктора. Тем не менее на мой взгляд риск в данном случае оправдывается отсутствием необходимости проверки на 0. Но допустим, что параметр конструктора — указатель, что в этом случае говорит против использования ссылки в качестве поля? Где можно "нарваться"?

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

I>Конкретный пример у тебя есть. Подправь.

Я же сказал. Я бы передавал УКАЗАТЕЛЬ в конструктор и его же и хранил бы...
и сделал бы приватный или защищённый метод, скажем dst(), или output() который бы возвращал бы ссылку...

I>Где можно "нарваться"?

Ну, например, если тыбе захочется реализовать оператор присваивания писателя, или завести массив (std::vector) писателей...

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

E>Я же сказал. Я бы передавал УКАЗАТЕЛЬ в конструктор и его же и хранил бы...
E>и сделал бы приватный или защищённый метод, скажем dst(), или output() который бы возвращал бы ссылку...

Ясно, спасибо. Думал может тебе код использующий writer подправить хочется, в смысле, само по себе наличие writer-а ты считаешь неправильным.

E>Ну, например, если тыбе захочется реализовать оператор присваивания писателя, или завести массив (std::vector) писателей...

Тогда я заменю ссылку на указатель.

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

I>Ясно, спасибо. Думал может тебе код использующий writer подправить хочется, в смысле, само по себе наличие writer-а ты считаешь неправильным.

Я не совсем понимаю что за код использует writer.
У тебя был пример этого класса, а не кода, который его использует.

I>Тогда я заменю ссылку на указатель.
И попадёшь на переписывание всего writer, как минимум...