Внутреннее устройство потоков

Очень тупой вопрос - почему std::ios хранит в своих потрохах указатель на объект std::streambuf, а не является потомком std::streambuf? Принимая во внимание что std::streambuf все равно собран на виртуальных функциях, а значит поведение std::ios один фиг в итоге задается через перегрузку этих самых виртуальных функций.

0

Сообщение от Renji Очень тупой вопрос - почему std::ios хранит в своих потрохах указатель на объект std::streambuf, а не является потомком std::streambuf?

Потому что назначение std::ios выполнять форматирование ввода/вывода, а std::streambuf читать/писать из/в устройства.

0

Сообщение от Ilot Потому что назначение std::ios выполнять форматирование ввода/вывода, а std::streambuf читать/писать из/в устройства.

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

0

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

0

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

Дык в std::streambuf полиморфизм и используется. Он работает только через перегруженные потомком методы.

Сообщение от ShadowFirst Компазиция это как раз то что там есть, то есть создается объект внутри класса, а не происходит наследование.

Не создается он. Объект std::streambuf (вернее, его потомок) должен создавать потомок, а потом передавать std::ios. И вот зачем такой изврат - я понять не могу.

0

Сообщение от Renji Но при этом эти два класса не являются самостоятельными сущностями.

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

посмотрите внимательно на этот пример:
http://www.cplusplus.com/reference/ios/ios/rdbuf/

представьте себе, что std::ios - это магнитофон.
магнитофоны бывают разные.
они по разному воспроизводят получаемые данные.

а std::streambuf - устройство, которое непосредственно работает
с физическим источником данных:
кассеты, пластинки, копакт диски.
назовем его "стриммером".

любые stl-compatible магнитофоны умеют
с любыми stl-compatible стриммерами.
благодаря стандартизированному интерфейсу.

данная архитектура позволяет извлечь стриммер из одного магнитофона,
и вставить его в другой.

таким образом, получается, что std::streambuf определяет,
как прочитать байтики из источника.
а std::ios определяет, как эти байтики интерпритировать.

пример:
можно подсунуть std::streambuf в корпус zipstream, и поиметь зазипованный архив так же просто,
как и обычный текстовый/бинарный файл.

можно подсунуть какой нибудь замороченный custom::streambuf в обычный std::cout,
и вывести в консольку данные с како нибудь сильно замороченного носителя.

0

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

Пример паттерна "мост". Разделение интерфейса и реализации. Чтение/запись для разных устройств на разных платформах разный. Подобное разделение позволяет писать код вне зависимости от устройства/платформы.
Тем более, что и обязанности у них разные:

Сообщение от Ilot Потому что назначение std::ios выполнять форматирование ввода/вывода, а std::streambuf читать/писать из/в устройства.

0

Сообщение от hoggy посмотрите внимательно на этот пример:

Посмотрел. Пример переопределяет поведение глобальной переменной cout. Нужно это только потому что программист не может поменять объявление этой глобальной переменной. И таких переменных в стандартной библиотеке целых три - cout, cin, cerr. Вся свистопляска ради трех переменных что ли?

Сообщение от hoggy можно подсунуть какой нибудь замороченный custom::streambuf в обычный std::cout, и вывести в консольку данные с како нибудь сильно замороченного носителя.

А можно тупо объявить глобальную переменную custom::iostream my_cout. Но понимаю, код прибит к cout гвоздями.

Сообщение от Ilot Пример паттерна "мост". Разделение интерфейса и реализации. Чтение/запись для разных устройств на разных платформах разный. Подобное разделение позволяет писать код вне зависимости от устройства/платформы.

Кросс-платформенная функция пишет через std::ostream&stream (дальний потомок std::ios). Объясните тупому на пальцах какая функции разница, есть внутри std::ostream паттерн "мост" или нет (ссылка std::ostream& скушает любых потомков std::ostream, с любыми перегрузками методов).

0

Сообщение от Renji Кросс-платформенная функция пишет через std::ostream&stream (дальний потомок std::ios).

Было же написанно и неоднократно std::ios не пишет/читает из устройства. Наследники этого класса управляют форматированием, а запись/чтение делегируют буферу. Можно прямо работать с буфером минуя потоки.

Сообщение от Renji Объясните тупому на пальцах какая функции разница, есть внутри std::ostream паттерн "мост" или нет (ссылка std::ostream& скушает любых потомков std::ostream, с любыми перегрузками методов).

Все верно. Так и задумывалось. Т.е. создать интерфейс для однообразной работы с разными устройствами. Но так как потоки переехали из распространенной в то время библиотеки ввода/вывода то вопросы следует задавать ее разработчикам.

1

Сообщение от Ilot Но так как потоки переехали из распространенной в то время библиотеки ввода/вывода то вопросы следует задавать ее разработчикам.

А, то есть такая архитектура по наследству досталась. Это уже понятнее, спасибо.

0

Сообщение от Renji Вся свистопляска ради трех переменных что ли?

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

0

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

Эта возможность есть и при наследовании std::ios от streambuf.

0

Сообщение от Renji Эта возможность есть и при наследовании std::ios от streambuf.

есть особое устройство, которое стандартный streambuf не поддерживает.

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

зачем мне велосипедить стандартный стрим,
если достаточно завелосипедить только наследника std::streambuf,
а весь остальной код останется без изменений?
зачем велосипедить, если можно по максимуму использовать stl ?

так реализуется идеома "закрыт для изменений, открыт для расширений".
весь уже написанный и протестированный код остается без изменений.
функционал наращивается, но старый не изменяется.

конечно, в суровой реальности все не так безоблачно прекрасно.
но в целом эта идея работает.

0

Сообщение от hoggy зачем мне велосипедить стандартный стрим, если достаточно завелосипедить только наследника std::streambuf, а весь остальной код останется без изменений?

Ткните пальцем, где в моем примере с наследованием, меняется код не относящийся к streambuf.

0

Сообщение от Renji Ткните пальцем, где в моем примере с наследованием, меняется код не относящийся к streambuf.

выше я приводил вам пример подмены стриммера.

приведите мне аналогичный пример.

с использованием вашего подхода.

требуются преобразования:

zipstream <---> ostream, fstream.

наследник streambuf читает видеопоток,
и распознает особые маркеры среди потока байтиков,


то есть не обязательно писать код алгоритмов.
интересует архитектурное решение.

ваш bicycle_stream сейчас нарушают идеому
"закрыт для изменений, открыт для расширений".

нужно знать про какой то bicycle_stream,
что бы записать данные на диск?

0

Сообщение от hoggy приведите мне аналогичный пример.

0

Сообщение от Renji stream<<"Мы принимаем любых потомков ostream! Вы хотели напечатать: "<<str;

у меня в исходном коде фигурирует:

мне теперь код переписывать придется?

0

Сообщение от hoggy у меня в исходном коде фигурирует:

А у меня фигурирует:
Теперь дописываем к этому делу is.rdbuf(cin.rdbuf()) и программа падает. Потому как cin никаких seekg скорее всего не поддерживает.

Сообщение от hoggy мне теперь код переписывать придется?

Конечно. Программа должна быть изначально рассчитана на работу с произвольным потоком. В документации должно быть изначально подписано что этот поток должен поддерживать. Иначе попытки заменить один поток другим будут иметь непредсказуемые последствия. Если же программа уже рассчитана на поддержку произвольных потоков, то и rdbuf костыль ей без надобности.

0