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

V>В качестве посылки, я так понимаю не только и не столько избыточная функциональность. Поясню: если "тащить" дальше весь iostream, то с увеличением количества кода и разработчиков, использующих его, будет также увеличиваться количество ошибок: структурных, функциональных и пр., вследствии недостаточного понимания принципиального отличия(а оно есть и большое) нового iostream, также периодическое забывание того, что у нового не поддерживается более половины функциональности старого. Тоже будет наблюдаться и в процессе поддержки нового iostream. Плюс присутствуют некоторые накладные расходы (1-3 процента, но все же). Так что всплывает и мотивация — снятие излишней нагрузки (в дальнейшем) с разработчиков за счет определенного количества первоначальных затрат.

В моем понимании никакого принципиального отличия нет — мы используем тот же поток, но с усовершенствованны буфером. Почему отличий нет? Поясню, мы работаем с файлами, выполняем операции чтения/записи, с новым буфером мы будет выполнять те же операции, потому парадигма потока будет применима и здесь. Прежде чем предлагать отказ от старой, неплохо бы озвучить идею нового метода работы с файлами. Тем более у нового буфера будет поддерживаться вся функциональность filebuf за счет наследования от него и перегрузки только нужных методов.