Здравствуйте Sergey, Вы писали:
S>Как несложно заметить, я отвечал на вопрос Александра Митрошина, где ни слова не было сказано о том, что свой filebuf был написан с ошибками. Что же касательно здесь
Насчет ошибок никто не говорил...некоторые недоработки, возможно...
S>Никакого "старого отмершего буфера" быть не должно. Должен быть только новый буфер — наследник старого.
S>Перегрузка функций std::basic_ostream, работающих с буфером, в наследнике — достаточно странная идея сама по себе.
S>Разработчик "нового" стрима, совместимого со стандартным, разрабытавает его следующим образом:
S>1) Пишет своего наследника std::basic_streambuf, реализующего необходимые примитивные операции. Для определенности назовем его my_super_duper_filebuf. Самая сложная часть работы.
Тут сделано так — взят filebuf и перегружены отдельные его функции — seekoff, seekpos, xsgetn, xsputn. В них, если новый буфер (реализованный отдельным классом), не был проинициализирован, вызывались функции оригинального filebuf, если был проинициализирован, то использовалиь функции нового буфера. Я так понимаю, что правильнее было сделать свой класс — наследник напрямую от streambuf? Просто при использовании filebuf'а все как-то проще прошло, но, возможно, мы не видим подводных камней в таком способе реализации...
S>2) Пишет "свои" my_super_duper_istream/my_super_duper_ostream и т.д: S> заводит переменную-член класса типа my_super_duper_filebuf. S> пишет конструкторы, инициализирующие (или нет — но это чуть-чуть сложнее ) my_super_duper_filebuf и вызывающие конструкторы предка и передающих ему ссылку на my_super_duper_filebuf S> при необходимости, дописывает пару-тройку функций, специфичных для данного класса — например, is_open/close/open для файловых стримов и т.д.
Здравствуйте Митрошин Александр, Вы писали:
S>>1) Пишет своего наследника std::basic_streambuf, реализующего необходимые примитивные операции. Для определенности назовем его my_super_duper_filebuf. Самая сложная часть работы.
МА>Тут сделано так — взят filebuf и перегружены отдельные его функции — seekoff, seekpos, xsgetn, xsputn. В них, если новый буфер (реализованный отдельным классом), не был проинициализирован, вызывались функции оригинального filebuf, если был проинициализирован, то использовалиь функции нового буфера. Я так понимаю, что правильнее было сделать свой класс — наследник напрямую от streambuf? Просто при использовании filebuf'а все как-то проще прошло, но, возможно, мы не видим подводных камней в таком способе реализации...
Ну раз встал вопрос о переписывании, значит, все-таки видите Накой вам старый буфер вообще понадобился — вы же все равно работаете или с новым, или со старым? Соответственно, нужны два разных стрима (если нужны), а не два буфера в одном стриме.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>Ну раз встал вопрос о переписывании, значит, все-таки видите Накой вам старый буфер вообще понадобился
Ну, видимо, из-за недостатка знаний , тем более, сначала мы думали, что одним read'ом обойдемся...я заглянул в filebuf и слегка испугался, потому решил просто xsgetn перегрузить. Потом, правда, понадобился и write. Так, я правильно понял, можно наследоваться от streambuf, перегрузить пять функций (seek's, write/read, flush) и все работать будет?!
Кстати, раз пошла такая пьянка, у нас тут мысль родилась, что может быть правильнее (если абстрагироваться от потребного на это времени и ресурсов) сделать объектное отображение наших файлов?
Здравствуйте Митрошин Александр, Вы писали:
S>>Ну раз встал вопрос о переписывании, значит, все-таки видите Накой вам старый буфер вообще понадобился
МА>Ну, видимо, из-за недостатка знаний , тем более, сначала мы думали, что одним read'ом обойдемся...я заглянул в filebuf и слегка испугался, потому решил просто xsgetn перегрузить.
Если это была та библиотека, что с VC 6.0 идет, то и правда ужас. Я тоже сначала с него все содрал, потом статейки умные на эту тему почитал и понял, что это был мазохизм
МА>Потом, правда, понадобился и write. Так, я правильно понял, можно наследоваться от streambuf, перегрузить пять функций (seek's, write/read, flush) и все работать будет?!
Нет, это говорилось совсем в другом контексте, относительно самих стримов, а не буферов — если эти пять функций у стрима работают правильно, то остальные тоже будут работать правильно. Для буферов же надо перегружать seekoff, seekpos, setbuf, sync, overflow, underflow. Иногда имеет смысл переопределить showmanyc. Ну и если охота потрахаться с локалями, то наверное и imbue, но я этого не пробовал .
Для начало можно смотреть здесь: http://ou800doc.caldera.com/SDK_clib/_Deriving_New_streambuf_Classes.html
МА>Кстати, раз пошла такая пьянка, у нас тут мысль родилась, что может быть правильнее (если абстрагироваться от потребного на это времени и ресурсов) сделать объектное отображение наших файлов?
Да кто ж знает, что у вас за файлы и что за отображение им потребно...
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
) my_super_duper_filebuf и вызывающие конструкторы предка и передающих ему ссылку на my_super_duper_filebuf
, тем более, сначала мы думали, что одним read'ом обойдемся...я заглянул в filebuf и слегка испугался, потому решил просто xsgetn перегрузить. Потом, правда, понадобился и write. Так, я правильно понял, можно наследоваться от streambuf, перегрузить пять функций (seek's, write/read, flush) и все работать будет?! 
