Не нашел такой темы...

как в с++ запретить наследование класса? 
в .net эта штука, насколько я понимаю называется sealed. А как здесь?

Это сообщение отредактировал(а) Fedor - 17.6.2007, 12:26

сделать конструкторы private. А для создания объекта написать "фабричный метод"

типа

??

Добавлено через 4 минуты и 3 секунды
Хотя так не пойдет... В общем, как это фабричный метод? )

Я понимаю так.


Добавлено через 1 минуту и 53 секунды
Ну или так:

Fedor,  а какой компилятор используеш?    В зависимости от компилятора, можно директивами заставить не наследовать класс... Всё зависит от компилятора (и его версии)   

    

Если комилятор для C#, то можно приписать sealed?   

Ну, так не интересно. Если тема в разделе C++, то и компиляторы должны быть для С++. 

Damarus, ну это был риторический вопрос автору идеи 

Вопрос на засыпку: Назовите внятную и вескую причину, Зачем нужно запрешать наследование? Тем самым нарушая основной принцип ООП.

Fin, какой принцип? Где написано, что все классы должны иметь способность к классическому наследованию?

Это сообщение отредактировал(а) Xenon - 17.6.2007, 16:15

Xenon, Открой любой учебник, где хотя бы краем упоминается Объектно Оринтированное Программирование. Там обязательно будут упоменены три кита ООП: инкапсуляция, наследование и полиморфизм.

Fin, давай без фанатизма, а? то, что аксиоматическим началом эвклидовой геометрии является непересекаемость параллельных прямых вовсе не означает, что все прямые должны быть параллельны   

Ну я так и не услышал причину? Или запретить ради запрешения  В принципе на С++ я знаю как обойти данное закрытие наследования. Нужен только большой бубен и полчаса работы.

Fin, открыл, ну и? Да, согласен, в ООП есть и инкапсуляция и полиморфизм и наследование ... Что, я теперь в каждом классе должен все функции помечать как virtual, приватные члены делать защищенными? А, ну тогда еще нельзя использовать friend, так как друзья - палки в колеса настоящему ООП.
Свою очередь могу посоветовать открыть Страуструпа на 23 главе "Разработка и проектирование"

Fedor, лучше запретить деструктор - тогда будет класс как класс, но без возможности наследования.


Fin, поверь, причины бывают... как правило архитектурные.

Добавлено через 1 минуту и 6 секунд
эээ... хотя, туплю... класс как класс не буит...   сорри за запутывание...

Fin, не знаю, быть может, мой пример - ошибка проектирования...Кроме того, не знаю, возможен ли такой поворот событий в С++(пример пришел из опыта программирования на Delphi)
были у меня объекты. реально конструируемые. а потом возникла потребность скрыть конструктор и сделать фабричный метод, чтоб предотвратить создание логически одинаковых объектов. И вот занаследует человек мой класс(ещё вопрос - зачем) и в своем конструкторе сделает вызов... моего фабричного метода. И фабричный метод найдет подходящий объект и увеличит его счетчик ссылок, или не найдет и создаст новый объект, который канет в бездну... В любом случае, человек со своим наследником моего класса не получит то, чего ожидал - вызов конструктора предка для дополнительной инициализации. Можно, конечно, раскомментировать случаи использования как только можно. Но безопасней было бы запретить наследование. И, если ему(клиенту) надо будет - пусть делает композицию с моим объектом. 
В общем, как на меня, запрет наследования был бы "в кассу" если необходимо предотвратить работу с фабричными методами вместо обычных конструкторов 
P.S. Кидайте помидоры, мне даже интересно, где ошибся при проектировании 

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

Товарищи, чем вас не устраивает мой вариант?   

MAKCim, в принципе неплохо, но по-моему не очень очевидная реализация 

А виртуальное наследование то зачем, если предполагается, что от класса A унаследовать больше нельзя?

Vyacheslav, 
а если комментарии прочитать   

Vyacheslav, без виртуального наследования производные классы от A можно будет строить

Вопрос снят 

зато действенная
и объекты класса A можно без напряга создавать

MAKCim, минус твоей реализации: оверхэд из-за виртуального наследования. Ну это так - для общей картины .

Компилирется gcc без ошибок

Добавь конструкторы или явно инстанцируй C

есть вариант лучше?

MAKCim, я же специально сказал:

Можно сделать как у тебя и поиметь удобство(+) и оверхэд(-). Можно сделать иначе и поиметь неудобство(-) и скорость(+). Смотря что критичней - зависит от ситуации. Лучших решений не бывает. Бывают рациональные.

надо бы проверить насколько мой вариант уступает в скорости (если вообще уступает)
если использовать static функцию + new

то однозначно мой вариант быстрее в случае статических объектов 

и немного уступает в случае динамического создания 

засчет дополнительного создания объекта класса B, но класс B - пустой и при достаточной оптимизации подобъект этого класса вообще можно не создавать