А где вы используете private наследование?

@Undisputed · Регистрация: 10.06.2014

Студворк — интернет-сервис помощи студентам

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

@~~dawn artist~~ · 30.06.2017, 19:18

Сообщение от Undisputed

На мой взгляд это может понадобится если нужно по определенным причинам выдать один тип за другой за счёт базового.

Как раз с приватным наследованием это не получится.

Убежденный · 30.06.2017, 19:30

См. Boost.NonCopyable, например.
Это класс, наследуясь от которого, мы запрещаем копирование объекта.
Здесь наследование как раз должно быть приватным, иначе потенциальные
наследники класса могли бы получить доступ к запрещенным функциям...

noncopyable
http://www.boost.org/doc/libs/... yable.html

Добавлено через 15 секунд
См. Boost.NonCopyable, например.
Это класс, наследуясь от которого, мы запрещаем копирование объекта.
Здесь наследование как раз должно быть приватным, иначе потенциальные
наследники класса могли бы получить доступ к запрещенным функциям...

noncopyable
http://www.boost.org/doc/libs/... yable.html

@Undisputed · 30.06.2017, 21:23 **[ТС]**

daun-autist,
Это потому что ничего из базового класса нельзя будет вызвать что либо?
А как насчёт трюков в отношении метапрограммирования?

Убежденный,
Там класс вроде пустой. Запрещение копирования происходит за счёт того что конструктор родительского класса недоступен?

MrGluck · 30.06.2017, 21:46

Для миксинов. Пример см выше -

Сообщение от Убежденный

Boost.NonCopyable

@~~dawn artist~~ · 30.06.2017, 22:01

Почему здесь не запрещено задавать вопросы, на которые уже есть ответы?

Добавлено через 7 минут

Сообщение от Undisputed

Это потому что ничего из базового класса нельзя будет вызвать что либо?

Потому что такое правило, что только public-наследование выражает отношение "является".

@Undisputed · 01.07.2017, 11:42 **[ТС]**

MrGluck, daun-autist,
Спасибо за помощь

Добавлено через 13 часов 37 минут
Убежденный,
Разобрался вроде. Просто запрещается копирование родительского класса и все, поэтому с помощью конструктора по умолчанию копировать объект не получается(да и создать тоже)...

daun-autist,
А откуда вы взяли такое правило? Ваше утверждение судя по всему не действительно

Потому что такое правило, что только public-наследование выражает отношение "является".

C++

//g++  5.4.0
 
#include <iostream>
 
class foo{};
class bar : private foo{};
 
int main()
{
    std::cout << std::is_base_of<foo, bar>::value;
}

http://rextester.com/QKM99837

Croessmah · 01.07.2017, 12:55

Undisputed, выше ссылка на isocpp faq.
Вы ппутаете ООП концепции и C++. Мешаете как хотите их.
Наследование в C++ и "отношения" классов в ООП это как бэ разные вещи.
Одно может наследоваться от другого, но не удовлетворять требованиям "является".
Вы не можете использовать bar так, как будто это foo, т.к. наследование приватное.
Только сам класс bar может работать так, как будто он foo,
но внешний код так уже работать не может, так что никакого is-a здесь нет.

Зато приватное наследование вполне подходит под композицию (has-a).

@Undisputed · 01.07.2017, 13:50 **[ТС]**

Croessmah
Ну если говорить чисто о терминологии и определениях то да, я с вами полностью согласен.
Под понятием "является" я понимал именно возможность определить наличие родительского класса в дереве наследования независимо от типа наследования.

@Avazart · 01.07.2017, 21:55

Не по теме:

private-наследование это отношение "содержит", обычно...

@hoggy · 01.07.2017, 22:40

Сообщение от Undisputed

Но хотелось бы узнать мнение более опытных

нафиг не нужно на практике.

@Kastaneda · 02.07.2017, 10:41

Плюс еще одно применение private наследования - у базового класса нет виртуального деструктора и мы хотим запретить приводить указатель на дочерний класс к указателю на базовый (чтоб не было проблем с вызовом деструктора). На практике я 1 раз в жизни так делал)

@hoggy · 02.07.2017, 10:57

Сообщение от Kastaneda

Плюс еще одно применение private наследования - у базового класса нет виртуального деструктора и мы хотим запретить приводить указатель на дочерний класс к указателю на базовый

нафига там тогда полиморфизм?

@Kastaneda · 02.07.2017, 11:48

Сообщение от hoggy

нафига там тогда полиморфизм?

а его там и нет) Просто расширение класса.

@Avazart · 02.07.2017, 12:10

Сообщение от Kastaneda

Плюс еще одно применение private наследования - у базового класса нет виртуального деструктора и мы хотим запретить приводить указатель на дочерний класс к указателю на базовый (чтоб не было проблем с вызовом деструктора). На практике я 1 раз в жизни так делал)

Чем это лучше обычной композиции?

@Undisputed · 02.07.2017, 12:41 **[ТС]**

Avazart,
Может же быть так что нам не нужен экземпляр базового класса(а композиция требует этого), и полиморфизм тоже не нужен, но при этом нескольким наследникам требуется функциональность этого базового класса т.к он для них общий.

Например для реализации инкапсуляции часто используются методы setSomething, getSomething и чтоб не повторять эти методы во всех классах где нужен функционал этого Something-a очень даже удобно выделить сеттер и геттер в отдельный класс и наследовать эти методы

@mat_for_c · 02.07.2017, 12:41

Сообщение от Убежденный

См. Boost.NonCopyable, например.
Это класс, наследуясь от которого, мы запрещаем копирование объекта.

Все же я не понял, для чего тут использовать private наследование, ведь можно самому указать, что копирование класса = delete;

@Avazart · 02.07.2017, 12:48

Сообщение от mat_for_c

Все же я не понял, для чего тут использовать private наследование, ведь можно самому указать, что копирование класса = delete;

До С++11, не было ...

Не по теме:

И честно говоря мне кажется так нагляднее...

@Undisputed · 02.07.2017, 12:49 **[ТС]**

mat_for_c,
Думаю все дело в том что у программистов есть хорошая привычка реализовывать заранее один раз часто используемый функционал и использовать его там где он нужен тем самым создав некий стандарт кодирования и удобство... То есть достаточно просто отнаследоваться от уже готового кода и не писать одно и то же по 100 раз. Да и до с++11 delete для методов вроде и нет.

Думаю как то так... Но посмотрим что скажет Убежденный

@Avazart · 02.07.2017, 12:52

Сообщение от Undisputed

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

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

Сообщение от Undisputed

То есть достаточно просто отнаследоваться от уже готового кода и не писать одно и то же по 100 раз.

Да но есть и другие подходы повторного использования, например использование сигналов/слотов.

@Undisputed 807 / 403 / 82 Регистрация: 10.06.2014 Сообщений: 2,522
	02.07.2017, 12:41 [ТС]	16
	Avazart, Может же быть так что нам не нужен экземпляр базового класса(а композиция требует этого), и полиморфизм тоже не нужен, но при этом нескольким наследникам требуется функциональность этого базового класса т.к он для них общий. Например для реализации инкапсуляции часто используются методы setSomething, getSomething и чтоб не повторять эти методы во всех классах где нужен функционал этого Something-a очень даже удобно выделить сеттер и геттер в отдельный класс и наследовать эти методы 0

@~~dawn artist~~ Заблокирован
	30.06.2017, 19:18	2
	Сообщение от Undisputed На мой взгляд это может понадобится если нужно по определенным причинам выдать один тип за другой за счёт базового. Как раз с приватным наследованием это не получится. 1

Убежденный Ушел с форума 16458 / 7422 / 1186 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	30.06.2017, 19:30	3
	Сообщение было отмечено Undisputed как решение Решение См. Boost.NonCopyable, например. Это класс, наследуясь от которого, мы запрещаем копирование объекта. Здесь наследование как раз должно быть приватным, иначе потенциальные наследники класса могли бы получить доступ к запрещенным функциям... noncopyable http://www.boost.org/doc/libs/... yable.html Добавлено через 15 секунд См. Boost.NonCopyable, например. Это класс, наследуясь от которого, мы запрещаем копирование объекта. Здесь наследование как раз должно быть приватным, иначе потенциальные наследники класса могли бы получить доступ к запрещенным функциям... noncopyable http://www.boost.org/doc/libs/... yable.html 3

@Undisputed 807 / 403 / 82 Регистрация: 10.06.2014 Сообщений: 2,522
	30.06.2017, 21:23 [ТС]	4
	daun-autist, Это потому что ничего из базового класса нельзя будет вызвать что либо? А как насчёт трюков в отношении метапрограммирования? Убежденный, Там класс вроде пустой. Запрещение копирования происходит за счёт того что конструктор родительского класса недоступен? 0

MrGluck Форумчанин 8194 / 5044 / 1437 Регистрация: 29.11.2010 Сообщений: 13,453
	30.06.2017, 21:46	5
	Для миксинов. Пример см выше - Сообщение от Убежденный Boost.NonCopyable 1

@~~dawn artist~~ Заблокирован
	30.06.2017, 22:01	6
	Почему здесь не запрещено задавать вопросы, на которые уже есть ответы? Добавлено через 7 минут Сообщение от Undisputed Это потому что ничего из базового класса нельзя будет вызвать что либо? Потому что такое правило, что только public-наследование выражает отношение "является". 1

Croessmah Неэпический 17813 / 10585 / 2043 Регистрация: 27.09.2012 Сообщений: 26,625 Записей в блоге: 1
	01.07.2017, 12:55	8
	Undisputed, выше ссылка на isocpp faq. Вы ппутаете ООП концепции и C++. Мешаете как хотите их. Наследование в C++ и "отношения" классов в ООП это как бэ разные вещи. Одно может наследоваться от другого, но не удовлетворять требованиям "является". Вы не можете использовать bar так, как будто это foo, т.к. наследование приватное. Только сам класс bar может работать так, как будто он foo, но внешний код так уже работать не может, так что никакого is-a здесь нет. Зато приватное наследование вполне подходит под композицию (has-a). 1

@Undisputed 807 / 403 / 82 Регистрация: 10.06.2014 Сообщений: 2,522
	01.07.2017, 13:50 [ТС]	9
	Croessmah Ну если говорить чисто о терминологии и определениях то да, я с вами полностью согласен. Под понятием "является" я понимал именно возможность определить наличие родительского класса в дереве наследования независимо от типа наследования. 0

@Avazart
	01.07.2017, 21:55 #10
	Не по теме: private-наследование это отношение "содержит", обычно... 0

@hoggy 8724 / 4304 / 958 Регистрация: 15.11.2014 Сообщений: 9,751
	01.07.2017, 22:40	11
	Сообщение от Undisputed Но хотелось бы узнать мнение более опытных нафиг не нужно на практике. 0

@Kastaneda 5229 / 3201 / 362 Регистрация: 12.12.2009 Сообщений: 8,112 Записей в блоге: 2
	02.07.2017, 10:41	12
	Плюс еще одно применение private наследования - у базового класса нет виртуального деструктора и мы хотим запретить приводить указатель на дочерний класс к указателю на базовый (чтоб не было проблем с вызовом деструктора). На практике я 1 раз в жизни так делал) 0

Опции темы

@hoggy 8724 / 4304 / 958 Регистрация: 15.11.2014 Сообщений: 9,751
	02.07.2017, 10:57	13
	Сообщение от Kastaneda Плюс еще одно применение private наследования - у базового класса нет виртуального деструктора и мы хотим запретить приводить указатель на дочерний класс к указателю на базовый нафига там тогда полиморфизм? 0

@Kastaneda 5229 / 3201 / 362 Регистрация: 12.12.2009 Сообщений: 8,112 Записей в блоге: 2
	02.07.2017, 11:48	14
	Сообщение от hoggy нафига там тогда полиморфизм? а его там и нет) Просто расширение класса. 1

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	02.07.2017, 12:10	15
	Сообщение от Kastaneda Плюс еще одно применение private наследования - у базового класса нет виртуального деструктора и мы хотим запретить приводить указатель на дочерний класс к указателю на базовый (чтоб не было проблем с вызовом деструктора). На практике я 1 раз в жизни так делал) Чем это лучше обычной композиции? 0

@mat_for_c 223 / 213 / 80 Регистрация: 26.04.2013 Сообщений: 972
	02.07.2017, 12:41	17
	Сообщение от Убежденный См. Boost.NonCopyable, например. Это класс, наследуясь от которого, мы запрещаем копирование объекта. Все же я не понял, для чего тут использовать private наследование, ведь можно самому указать, что копирование класса `= delete;` 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	02.07.2017, 12:48	18
	Сообщение от mat_for_c Все же я не понял, для чего тут использовать private наследование, ведь можно самому указать, что копирование класса = delete; До С++11, не было ... Не по теме: И честно говоря мне кажется так нагляднее... 0

@Undisputed 807 / 403 / 82 Регистрация: 10.06.2014 Сообщений: 2,522
	02.07.2017, 12:49 [ТС]	19
	mat_for_c, Думаю все дело в том что у программистов есть хорошая привычка реализовывать заранее один раз часто используемый функционал и использовать его там где он нужен тем самым создав некий стандарт кодирования и удобство... То есть достаточно просто отнаследоваться от уже готового кода и не писать одно и то же по 100 раз. Да и до с++11 delete для методов вроде и нет. Думаю как то так... Но посмотрим что скажет Убежденный 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	02.07.2017, 12:52	20
	Сообщение от Undisputed Думаю все дело в том что у программистов есть хорошая привычка реализовывать заранее один раз часто используемый функционал и использовать его там где он нужен тем самым создав некий стандарт кодирования и удобство... В идеале это так, на практике это применимо когда решается схожие задачи. А когда каждый раз новая задача приходится писать новый код, переписывать старый или искать другую библиотеку. Сообщение от Undisputed То есть достаточно просто отнаследоваться от уже готового кода и не писать одно и то же по 100 раз. Да но есть и другие подходы повторного использования, например использование сигналов/слотов. 0

А где вы используете private наследование?

Решение