Могут ли средства вставки и извлечения iostream быть членами класса вместо глобальных перегрузок?

Вы получаете больше гибкости, отделяя определения ‹‹ и >> от отображаемого объекта.

Прежде всего, вы можете захотеть отображать тип, не относящийся к классу, например, перечисление или указатель. Предположим, у вас есть класс Foo, и вы хотите напечатать указатель на Foo. Вы не можете сделать это, добавив функцию-член в Foo. Или вы можете захотеть отобразить шаблонный объект, но только для определенного параметра шаблона. Например, вы можете отобразить вектор‹целое> в виде списка, разделенного запятыми, а вектор‹строка> – в виде столбца строки.

Другая причина может заключаться в том, что вам не разрешено или вы не хотите изменять существующий класс. Это хороший пример принципа открытости/закрытости в объектно-ориентированном проектировании, когда вы хотите, чтобы ваши классы были открыты для расширения, но закрыты для модификации. Конечно, ваш класс должен выставлять часть своей реализации, не нарушая инкапсуляцию, но это часто бывает (векторы выставляют свои элементы, комплекс выставляет Re и Im, строка выставляет c_str и т. д.).

Вы даже можете определить две разные перегрузки ‹‹ для одного и того же класса в разных модулях, если это имеет смысл.

Для перегрузки операторов потока Стандарт не накладывает ограничений на то, должны ли они быть членами или не членами, поэтому в идеале они могут быть. Фактически, большинство операторов вывода и ввода потока, определенных стандартной библиотекой, являются членами потока. классы.

Обоснование:

Почему inserters и extractors не перегружаются как функции-члены?

Обычно правило перегрузки операторов таково:

Если бинарный оператор изменяет свой левый операнд, обычно полезно сделать его функцией-членом типа своего левого операнда (поскольку обычно требуется доступ к закрытым членам операндов).

По этому правилу операторы потока должны быть реализованы как члены типа их левого операнда. Однако их левые операнды — это потоки из стандартной библиотеки, и нельзя изменить типы потоков стандартной библиотеки. Следовательно, при перегрузке этих операторов для пользовательских типов они обычно реализуются как функции, не являющиеся членами.

У меня был тот же вопрос раньше, и похоже, что вставки и экстракторы должны быть глобальными. Для меня это нормально; Я просто хочу избежать создания дополнительных «дружеских» функций в моем классе. Вот как я это делаю, т.е. предоставляю общедоступный интерфейс, который может вызывать "‹‹":

class Rock {
    private:
        int weight;
        int height;
        int width;
        int length;

    public:
        ostream& output(ostream &os) const {
            os << "w" <<  weight << "hi" << height << "w" <<  width << "leng" << length << endl;
            return os;
        }
    };

    ostream& operator<<(ostream &os, const Rock& rock)  {
        return rock.output(os);
    }

Я пропустил какие-либо другие проблемы?

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

Обычный outfile << var1 << var2 << var3; — довольно «линейный» синтаксис. И, поскольку в обоих случаях мы читаем слева направо, имена будут в том же порядке, что и в файле.

Вы планируете сделать синтаксис нелинейным. Читателю-человеку придется пропустить вперед и вернуться, чтобы увидеть, что происходит. Это усложняет задачу. А вы идете еще дальше. Чтобы прочитать вашу последнюю строку, r >>= "Your rational number is " >>= cout; вам сначала нужно прочитать >>=, чтобы увидеть, что вам нужно перейти к последнему слову (или около того), прочитать «>>= cout», вернуться к началу строки , прочитать строку вперед и т.д. В отличие от перемещения вашего глаза (глаз) от одного токена к другому, когда мозг может конвейеризировать весь процесс.

У меня есть несколько лет опыта работы с языком с таким нелинейным синтаксисом. Теперь я изучаю возможность использования clang для «компиляции» C++ на этот язык. (Хотя по многим причинам.) Если это сработает, я буду намного счастливее.

Моя предпочтительная альтернатива — очень минимальная перегрузка оператора, которая вызывает только функцию-член. Если даже немного оптимизировать, он все равно исчезнет из созданного исполняемого файла.

Есть одно «очевидное» исключение из вышесказанного, когда у вас есть только одно чтение/запись в операторе, как в myobj >> cout;

В C++ бинарные операторы обычно не являются членами класса. Согласно Языку программирования C++ Бьярна Страуструпа, оператор +, каноническое представление — это глобальная функция, которая сначала копирует свой левый операнд, затем использует += для него с правым операндом, а затем возвращает результат. Таким образом, глобальные потоковые операторы не являются чем-то из ряда вон выходящим. Как упоминал Элс, мы ожидаем, что операторы потока будут членами классов потоков, а не классов данных.