История изменений
Исправление alysnix, (текущая версия) :
Пришло время охренительных открытий. Я вам тайну открою: множественное тоже. Т.е. class A: B, C так же добавит C причём полностью, включая указатель на vtable. Иначе каст с указателя на A в указатель на C не работал бы, а так просто смещение прибавляется и в путь.
не надо открывать америку, ее открыли до вас.
хватит болтать. лучше ответьте почему все пороки просто отношения - «использование»(смотри UML), вы перенесли именно на наследование?
Интересно, а зачем же тогда всякие умные люди советуют избегать наследования и заменять её композицией?
опять обтекаете тему. наследование не стоит применять там, где, я же выделил это в предыдушем посте - вам не нужна совместимость с наследуемым классом. если такая совместимость не нужна - значит наследование избыточно и только путает читателя. тут нужна композиция.
еще раз для тупых. наследование это технически композиция с ДЕКЛАРИРОВАНИЕМ СОВМЕСТИМОСТИ ДАННОГО ТИПА С ВКЛЮЧАЕМЫМИ ТИПАМИ, обеспечиваемой тем или иным образом.
для совсем тупых - КРИТИКА НАСЛЕДОВАНИЯ ЭТО КРИТИКА КОМПОЗИЦИИ, поскольку совместимость вообще никак в ваших аргументах не затрагивается. если вы только тронете совместимость, полетит вся ваша совместимость в интерфейсах, реализациях и проч пурга.
В общем я дам вам подсказку: всему виной принцип «разделяй и властвуй». Также в программизме называется декомпозицией. Применительно к ООП гуглите «инкапсуляция». Из всего этого следует что всё-таки композиция и наследование не равны. Если интересует практический смысл запрета - я вам его объяснил, на примере реализации тривью с отступами и как это всё переживёт обновление библиотеки с виджетами.
вы бредите.
Исходная версия alysnix, :
Пришло время охренительных открытий. Я вам тайну открою: множественное тоже. Т.е. class A: B, C так же добавит C причём полностью, включая указатель на vtable. Иначе каст с указателя на A в указатель на C не работал бы, а так просто смещение прибавляется и в путь.
не надо открывать америку, ее открыли до вас.
хватит болтать. лучше ответьте почему все пороки просто отношения - «использование»(смотри UML), вы перенесли именно на наследование?
Интересно, а зачем же тогда всякие умные люди советуют избегать наследования и заменять её композицией?
опять обтекаете тему. наследование не стоит применять там, где, я же выделил это в предыдушем посте - вам не нужна совместимость с наследуемым классом. если такая совместимость не нужна - значит наследование избыточно и только путает читателя. тут нужна композиция.
еще раз для тупых. наследование это технически композиция с ДЕКЛАРИРОВАНИЕМ СОВМЕСТИМОСТИ ДАННОГО ТИПА С ВКЛЮЧАЕМЫМИ ТИПАМИ, обеспечиваемых тем или иным образом.
для совсем тупых - КРИТИКА НАСЛЕДОВАНИЯ ЭТО КРИТИКА КОМПОЗИЦИИ, поскольку совместимость вообще никак в ваших аргументах не затрагивается. если вы только тронете совместимость, полетит вся ваша совместимость в интерфейсах, реализациях и проч пурга.
В общем я дам вам подсказку: всему виной принцип «разделяй и властвуй». Также в программизме называется декомпозицией. Применительно к ООП гуглите «инкапсуляция». Из всего этого следует что всё-таки композиция и наследование не равны. Если интересует практический смысл запрета - я вам его объяснил, на примере реализации тривью с отступами и как это всё переживёт обновление библиотеки с виджетами.
вы бредите.