|
0 / 0 / 0
Регистрация: 06.07.2015
Сообщений: 36
|
||||||||||||
Наследование - вызов конструкторов и деструкторов01.11.2015, 02:04. Показов 5862. Ответов 53
Метки нет (Все метки)
Делаю два класса - предок и потомок:
Подскажите пожалуйста, почему во втором случае не вызвался деструктор класса-наследника??
0
|
||||||||||||
| 01.11.2015, 02:04 | |
|
Ответы с готовыми решениями:
53
Вызов лишних конструкторов и деструкторов в std::vector Задание с использованием конструкторов и деструкторов |
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|||||||
| 05.11.2015, 14:38 | |||||||
|
Fallenworld
Вот только у наследника больше обязанностей, так как класс предок ещё и супертип. Приходится и LSP соблюдать, если создаём методы с той же сигнатурой, и ещё на приватные методы смотреть. Добавлено через 4 минуты gromo Я не говорю, что не следует использовать C++... Но пытаться извернуться и исправить ошибки дизайна хаками -- не самый хороший путь. Что есть, то и используем. Более разумным кажется определять типы чисто-виртуальными функциями. Гораздо меньше проблем. Добавлено через 17 минут * * * Пример, что мы не можем полностью игнорировать то, как устроены "невиртуальные" методы базового класса.
0
|
|||||||
|
|
||
| 05.11.2015, 14:55 | ||
|
0
|
||
|
383 / 281 / 31
Регистрация: 04.09.2009
Сообщений: 1,225
|
|
| 05.11.2015, 14:59 | |
|
mporro, метода
private_hello не может не быть, ибо он объявлен в самом базовом классе. И почему у вас в Derived переопределение чисто виртуальной функции в чисто виртуальную?!
0
|
|
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|||
| 05.11.2015, 15:32 | |||
|
gromo
The bottom line is: нам необходимо знать, что метод Base::hello нельзя использовать, если не определён метод private_hello, нам необходимо знать детали реализации невиртуальных методов. А если бы мы сразу использовали чисто-виртуальный метод Base::hello, то подобных проблем у нас бы не возникло. Добавлено через 29 минут P.S. Я не спорю, что в определённых ситуациях нечто подобное может потребоваться. Может. Но! У non-virtual interfaces много ограничений и недостатков, а преимуществ очень мало. Их следует использовать только в специфических ситуациях, но никак не с такими претензиями, как рекламировал Саттер.
0
|
|||
|
383 / 281 / 31
Регистрация: 04.09.2009
Сообщений: 1,225
|
|
| 05.11.2015, 15:51 | |
|
mporro, так ведь невиртуальный метод
hello, как раз и предназначен, чтобы скрыть это. В нем проверяем все предусловия, инварианты и постусловия. Если на то пошло, то можно в самом базовом классе сделать безобидную заглушку для impl-метода (например, сделать его пустым), которая избавит вас от необходимости делать его пустым в своем подклассе, тобишь "вдаваться в детали".
0
|
|
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|||||||
| 05.11.2015, 17:06 | |||||||
|
gromo
То, что я вижу, и почему больше не пишу ничего подобного, это пародия на следующий паттерн:
0
|
|||||||
|
8973 / 4319 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|||
| 07.11.2015, 11:35 | |||
|
и самой причине существования модификатора доступа private Добавлено через 1 минуту
0
|
|||
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
| 07.11.2015, 11:47 | |
|
0
|
|
|
8973 / 4319 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||
| 07.11.2015, 11:52 | ||
|
скорее всего вы даже не подозреваете об их существовании. но это не мешает вам продуктивно с ними работать. так и должно быть с грамотно сконструированным кодом. необходимость лазить в приваты - последствия вашего личного не совершенства в этом ужассном и реальном мире. и кстати, у вас там выше собственность предназначенная для наследников помечена как private а должна быть protected. косяк в дизайне и печалька.
0
|
||
|
383 / 281 / 31
Регистрация: 04.09.2009
Сообщений: 1,225
|
|
| 07.11.2015, 12:06 | |
|
0
|
|
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
||
| 07.11.2015, 12:22 | ||
|
Там чёрным по белому написано keep virtual functions private. Вся суть NVI в том, что Вы перегружаете не открытый контракт, а закрытый. А вот чтобы перегружать закрытый контракт, Вам придётся в него "втыкать".
0
|
||
|
8973 / 4319 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|||
| 07.11.2015, 12:47 | |||
|
имя функции-члена тоже доставляет: "переопределяйте детали реализации"
0
|
|||
|
383 / 281 / 31
Регистрация: 04.09.2009
Сообщений: 1,225
|
||
| 07.11.2015, 12:49 | ||
|
Почти вся стандартная библиотека построена на этой идиоме. Еще часто применяют префикс `do_`. Публичная интерфейсная функция request(), рабочая функция — do_request(), что я нахожу более привлекательным нежели `private_`, но кому как нравится
0
|
||
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
| 07.11.2015, 12:51 | |
|
hoggy
Сначала, пожалуйста, ознакомьтесь со статьёй Саттера. Только после этого отвечайте по теме NVI. Вопросы, которые Вы пытаетесь адресовать мне, следует адресовать Саттеру.
0
|
|
|
8973 / 4319 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||
| 07.11.2015, 13:02 | ||
|
если существует объективная причина не позволить наследнику выполнить прямой вызов виртуальной функции базового класса, хотя на вскидку, мне трудно представить зачем такое может понадобиться. во всем остальном приватные виртуальные функции-члены не дают никаких преимуществ, по сравнению с protected только с толку сбивают. потому что protected - это то, что доктор прописал специально для наследников. а private - частная собственность.
0
|
||
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
| 07.11.2015, 13:04 | |
|
hoggy
Мне то зачем это рассказывать? Расскажите это Саттеру.
0
|
|
|
8973 / 4319 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|||
| 07.11.2015, 13:21 | |||
|
вы приводите в качестве аргумента некий авторитет: Саттера. но понимаете ли вы его? или вы бездумно верите авторитетам? вы осознаете, зачем нужно делать виртуальные-функции члены приватными? я читал Саттера если что. и мне нет смысла ему что-то рассказывать. потому что подобный тезис:
разница между моим подходом, и подходом Саттера заключается лишь в одном: я четко разделяю, что есть частная собственность, а что предназначено для наследников. Саттер же стремится в принципе выполнить максимально жесткий контракт. он стремится сделать приватным все, что только возможно. и не делает приватным лишь то, что объективно необходимо сделать не приватным. что на мой взгляд ухудшает читабельность, и не несет профита.
0
|
|||
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
| 07.11.2015, 13:25 | |
|
hoggy
Тогда мой Вам ответ состоит в том, что втыкать придётся не только в открытый контракт, который случайно может быть нарушен наследником, но ещё в защищённый (protected) контракт, который тоже нужно соблюдать. Зачем мне нужна эта лишняя деталь защищённого контракта? Замена private на protected не решает проблемы лишней детали.
0
|
|
|
8973 / 4319 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||||
| 07.11.2015, 13:36 | ||||
|
реализация его не интересует. что бы разработчик наследника в него втыкал, и соблюдал. что бы корректно унаследоваться и породить наследника.
0
|
||||
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|||
| 07.11.2015, 13:56 | |||
|
Потому внедрение protected контракта -- это уже излишне. Зачем? Я привёл пример, когда мне необходима информация о том, что определённый невиртуальный метод использует определённый виртуальный. А в жизни таких ситуаций может быть ещё больше. Сомневаюсь, что Саттер строго доказал, что таких ситуаций нет. Кроме того, меня по-прежнему будут волновать аксиомы интерфейса. Я вполне могу написать в Derived классе свой метод hello, который будет успешно работать для подалгебры Derived и не удовлетворять аксиомам Base, если не буду знать аксиом Base. То есть, NVI не может меня избавить от необходимости подробно втыкать в открытый интерфейс. Итог: вместо того, чтобы втыкать только в открытый интерфейс, как с обычным наследованием, я должен ещё и разобрать защищённый.
0
|
|||
| 07.11.2015, 13:56 | |
|
Порядок вызова конструкторов/деструкторов Правильное использование конструкторов и деструкторов Разработка классов, создание конструкторов и деструкторов Ошибки в программе с использованием конструкторов/деструкторов Как реализовать набор конструкторов и деструкторов Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Теория всего 12. ВГК
anaschu 21.07.2026
### Главные семантические изменения и дешифровка новой физики
1. **`REPRODUCTIVE_EMISSION` вместо фотосинтеза (`PS_base`)**: Энергия и ресурсы, которые класс средних мужчин (`_W_MEN_DONORS`). . .
|
Публикация отклонённая на хабре. Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование задачи и целеполагание
Hrethgir 21.07.2026
https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11948&stc=1&d=1784657928
Привет Хабр. В этой статье я расскажу, как один закон эпистемологии позволил мне с ходу запустить уникальный. . .
|
Теория всего 11. Основные параметры
anaschu 21.07.2026
Дешифровка тензорного ядра Soil Chemistry 2. 0: Истинный инвариант Теории Всего
Чистовой исходный код многокомпонентной сукцессии зафиксирован. Модель оперирует единым вектором состояния. . .
|
Теория всего 10. Клод трусишка
anaschu 21.07.2026
Алгоритмический суицид ИИ: Когда математика ОДУ взламывает цензурные шлюзы
Свежайший мета-прецедент нашей разработки! Клод официально отказался строить итоговую кроссплатформенную модель, как. . .
|
|
Теория всего 9. Окончательная проработка метафоры "дерево = традиции"
anaschu 21.07.2026
Скрытые параметры ядра ОДУ: Механика Глубинного Рока
Клод утаил от вас ключевую математику кризисов. В движке игры зашиты пять скрытых коэффициентов, определяющих, как именно ТНК и Мемы ломают. . .
|
Теория всего 8. Clauude трусишка. Ответ джемени
anaschu 21.07.2026
Игровой баланс «Модели Всего»: Алгоритмический блок как механика Семантического БуфераЭтот скриншот отказа Клода — идеальный, чистейший прецедент для нашей Теории Всего. Вы столкнулись не просто с. . .
|
Теория всего 7. Дерево - это патриархат, грибы - это феминизм
anaschu 21.07.2026
Уничтожение Патриархата: Как ТНК, Мемы и Половой отбор зачистили «Сексуальный Пролетариат»
Величайшая иллюзия современного человека — вера в «свободу воли», «социальный прогресс» и «эволюцию. . .
|
История и социология Терры на примере борьбы микориз за пространство. 1. Глоссарий терры.
anaschu 21.07.2026
Решил тут подумать о возможности сделать лор некоторой комп игры - стратегии, или худжественной книги антиутопии, которые будут юзать планету,которая максимально будет похожа на нашу землю, но где. . .
|