В статье на примерах объясняется, как реализовать поддержку потокового ввода-вывода из стандартной библиотеки (<iostream>) для своих классов.

В тексте статьи будет часто встречаться слово «поток», что означает именно поток ввода-вывода ((i/o)stream), но не поток выполнения (thread). Потоки выполнения в статье не рассматриваются.

Введение

Потоки из стандартной библиотеки — мощный инструмент. Аргументом функции можно указать поток, и это обеспечивает ее универсальность: она может работать как со стандартными файлами (fstream) и консолью (cin/cout), так и с сокетами и COM-портами, если найти соответствующую библиотеку.

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

Вступление

Недавно при работе над проектом учебной практики возникла потребность из своего кода порождать произвольный процесс и одновременно читать его stdout и stderr. Так как приложение пишется исключительно для linux, я решил заодно разобраться с epoll. Для запуска процесса на просторах интернета была найдена маленькая библиотека, делающая как раз то, что нужно, да еще и оборачивающая ввод-вывод в привычные потоки из стандартной библиотеки (речь о <iostream>).


Вооружившись несколькими статьями про epoll, я уже было собирался писать код, если бы не одно «но» — для epoll нужен доступ к «сырым» файловым дескрипторам, а автор библиотеки не предоставляет public-доступа к ним. Методы класса, возвращающие дескрипторы, скрыты под грифом «protected».

Что делать?

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

Поэтому в голову пришла безумная третья мысль: почему бы не попытаться как-то красиво «взломать» ООП и «легально» получить доступ к protected-методу без вмешательства в исходный код библиотеки? О том, какие преграды возникли на этом пути и как помог C++14 в их преодолении, и пойдет рассказ в данной публикации.