c++ Еще один нубский вопрос

man принцип Барбары Лисков

1. protected-поля класса 2. Различные случаи коллективной работы с кодом

Я как бы читал эту Барбару .. Принцип (если в двух слова) derived может расширять, но не изменять свойства базового класса. Тут как бы вопрос назревает. Если отношения между классами соответствуют этому принципу (допустим мы на 100 процентов уверены что свойства не поменяются), все значит строим иерархию через наследование?

1. protected-поля класса 2. Различные случаи коллективной работы с кодом

'/>'

protected в смысле? Типа если уж наследование то грех не воспользоватся и такой фичей (естественно при необходимости). В смысле я пока не знаю в каких случаях это особенность (protected) могла бы быть настолько полезной чтобы мы прибегнули к наследованию.

По второму случаю. Работа с кодом вы миеете ввиду что мы можем поунаследовать с учетом конструкторов, деструкторов, операторов. (или позапрещать их) я вас правильно понял?

Специфические задачи с сужением типов.

Number * number = ...
if ( Int * intNumber = number->castTo<Int>() ) {
    printf("int: %d\n", intNumber->value());
} else if ( Float * floatNumber = number->castTo<Float>() ) {
    printf("float: %f\n", floatNumber->value());
}

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

Читай про паттерны, тот же GoF. Там есть разные интересные примеры использования наследования.

Ну вот если хотя бы теже паттерны открыть. Как ты тот же Адаптер или Template method без наследования реализуешь? К тому же при использовании наследования не надо объявлять заново интерфейс. А если ты будешь использовать композицию вместо наследования, то твой субкласс не будет таковым восприниматься.

Да вы правы нужно курить паттерны. По ходу пробелов еще слишком много у меня. Сейча смотррю иерархию классов исключений из stl там кода не много и все по сути (вроде как неплохой пример где наследование уместно). Спасибо все еще раз всем кто ответил.

Но хотелось бы увидить пример такого случая

«Стандартные» ситуации уже разжевали, добавлю одну особенность (empty base optimization). Часто применяется при написании шаблонного кода.

Если бы эту штуку запилили для композиции, то можно было бы сделать нормальные свойства, а так до сих пор get/set пишут.

а так до сих пор get/set пишут.

Что-то не соображу как это поможет. Раскроешь мысль?

Последний раз, когда я пытался их сделать, мне показалось, что это единственная проблема. Но сейчас я не осилил пробросить this в Set<int, A, &A::getValue> value, без его сохранения его в поле Set.

«Стандартные» ситуации уже разжевали, добавлю одну особенность (empty >base optimization). Часто применяется при написании шаблонного кода.

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