Ну, если считаете необходимым вызывать в потомках, делайте protected. Я же говорю: видимость должна отражать назначение.

Ну-ну, бедные-бедные ребята, эти авторы красных книжек с автором серии во главе: ушли лесом...

Прежде чем читать умные книжки, надо выучить букварь. А то получается "гляжу в книгу, а вижу фигу". У некоторых людей просто мания какая-то путать частное с общим.

А, то есть вы не осили букварь и теперь кругом видите фиги?    Сочувствую... 

Неумение внимательно читать книги, равно как и отсутствие самокритики, - это твоя проблема, а мне плевать на чужие проблемы :p

Это сообщение отредактировал(а) UnrealMan - 21.7.2008, 14:35

Ой, а можно пример моего невнимательного чтения книг? (Самокритику опустим.)

Контрпример можно найти прямо под носом: std::basic_ostream из стандартной библиотеки C++. Если пользователь захочет реализовать вывод  информации на некоторое устройство через потоки, то он может создать новый потоковый класс, унаследовав его от std::basic_ostream (подобно тому, как это делается для basic_ofstream и basic_ostringstream). Данный базовый класс - вовсе никакой не абстрактный, и наследование реализации здесь имеет место быть. Никаких противоречий с рассуждениями, приводимыми в прочитанных мной книгах классиков, здесь нет. То, что является потоком вывода, должно быть унаследовано от std::basic_ostream.

Я же не говорил, что нужно запретить наследование реализации. В некоторых случаях избежать ее нельзя или трудно, это верно. Пример хороший, он демонстрирует слабость стандартной библиотеки, которая вынуждает вас наследовать реализацию, когда вы хотите наследовать интерфейс. Стандартная библиотека C++ не идеальна, как и не идеален C++, в котором понятие интерфейса не имеет воплощения в синтаксисе языка. Учтите. кстати, что все-таки есть определенная разница между стандартной библиотекой языка и сторонней библиотекой, к которой я аппелировал в посте. Классы потоков зашиты во многих интерфейсах именно потому что они входят в состав стандартных средств, в этой ситуации наследование от них для того, чтобы быть повторно использованным, а не для того, чтобы повторно использовать (© не помню кто), может быть вполне оправдано.

Еще раз прочитайте то, что вы отцитировали: я же говорю «по умолчанию». Если вы можете обосновать необходимость использования чего-то в конкретном случае, это замечательно, пользуйтесь. В том посте, да и в следующем вашем комментарии про использовании print в наследниках, я вас поддержал. Собственно, я не понимаю, в чем педмет ваших претензий ко мне.

"Некоторых" - это вроде как немногочисленных? Откуда такая статистика?


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


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

От друзей, зарабатывающих на жизнь программированием, и из книжек.


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

Я так понял, что вы хотите наследоваться от basic_ostream в вашем примере, чтобы ваш класс мог использоваться там, где уже используется ostream, то есть — много где(здесь возникает аргумент о том, что стандартная библиотека отличается от обыкновенной — своей распространенностью; надеюсь, больше повторять не придется). Если вы хотели использовать какие-то protected-члены ostream, приведите, пожалуйста, пример, какие. Большая часть классов стандартной библиотеки не предназначена для наследования реализации, там никаких особо продуманных protected-интерфейсов нет, так что я с интересом бы послушал, что вам там приглянулось...

Люди, скажите плз может ли такому определению функции   соответствовать вызов 

NDQuattro, создавай отдельную тему!

ок, просто ради такой мелочи форум мусорить не хотелось что то))

Какие проблемы? Читай книги и не надо будет мусорить! (сорри   )

Этих друзей, видимо, сотни, каждый из которых программирует в своей уникальной предметной области и притом лично сообщил тебе статистические данные своей работы? Что-то с трудом верится. А иначе это получается не очень репрезентативно.


Это уже обнадёживает, правда не хватает немного конкретики (автор и название хотя бы одной из этих книг, глава, пункт, абзац).


По-моему, совершенно очевидно, зачем нужно это наследование. Во-первых, basic_ostream берёт на себя много рутинной работы, во-вторых, классу, переопределяющему операцию вывода <<, нет необходимости различать, в какой именно поток будут выводить информацию, будь это cout, объект типа ofstream, объект типа ostringstream или объект типа MyOStream - с каждым видом потока можно работать единообразно.


Я не понимаю, каким боком распространённость в данном плане на что-либо влияет.

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