Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Общие вопросы > Невиртуальный деструктор


Автор: zzkoderzzzx 16.10.2013, 15:43
Известно, что надо всегда делать деструктор виртуальным. 
Тем не менее он не становится виртуальным без участия программиста. 
Значит разработчиками С++ была предусмотрена ситуация, когда есть необходимость в невиртуальном деструкторе. 
Какие вы можете привести примеры таких ситуаций?

Автор: azesmcar 16.10.2013, 15:56
Цитата(zzkoderzzzx @  16.10.2013,  15:43 Найти цитируемый пост)
Известно, что надо всегда делать деструктор виртуальным.

откуда это известно? ничего подобного  smile 

Цитата(zzkoderzzzx @  16.10.2013,  15:43 Найти цитируемый пост)
Тем не менее он не становится виртуальным без участия программиста. 

правильно, потому-что это нужно далеко не всегда, ровно как и не всегда обыкновенная функция должна быть виртуальной.

Цитата(zzkoderzzzx @  16.10.2013,  15:43 Найти цитируемый пост)
Какие вы можете привести примеры таких ситуаций? 

весь STL

Автор: zzkoderzzzx 16.10.2013, 16:40
Цитата(azesmcar @ 16.10.2013,  15:56)
весь STL

STL использует классы, но при этом нарушает все парадигмы ООП. Поэтому пример не очень хороший.

Добавлено @ 16:41
Цитата(azesmcar @ 16.10.2013,  15:56)
не всегда обыкновенная функция должна быть виртуальной.

В настоящих ОО-языках все методы виртуальные.

Автор: azesmcar 16.10.2013, 16:57
Цитата(zzkoderzzzx @  16.10.2013,  16:40 Найти цитируемый пост)
STL использует классы, но при этом нарушает все парадигмы ООП. Поэтому пример не очень хороший.

что значит нарушает? Код STL вообще не обьектно ориентированный.

Цитата(zzkoderzzzx @  16.10.2013,  16:40 Найти цитируемый пост)
В настоящих ОО-языках все методы виртуальные.

вызов виртуального метода имеет накладные расходы и далеко не всегда имеет смысл делать функцию виртуальной.
все методы виртуальны в Java, но скажем в C# такого нет.

Автор: bems 16.10.2013, 16:58
Цитата(zzkoderzzzx @  16.10.2013,  16:40 Найти цитируемый пост)
В настоящих ОО-языках все методы виртуальные.

да, но далеко не всегда нужно применять ООП 

Автор: zzkoderzzzx 16.10.2013, 16:58
Цитата(azesmcar @ 16.10.2013,  16:57)
Код STL вообще не обьектно ориентированный.

не ОО код значит плохой код

Автор: bems 16.10.2013, 17:00
Цитата(zzkoderzzzx @  16.10.2013,  16:58 Найти цитируемый пост)
не ОО код значит плохой код

охлол

Автор: NoviceF 16.10.2013, 17:05
 smile По какому поводу обострение? Опять не прошёл собеседование из-за проблем с плюсами?

Автор: vinter 16.10.2013, 17:24
Цитата

STL использует классы, но при этом нарушает все парадигмы ООП

О как. Давай-ка по пунктам, на примере std::vector, расскажи какие-такие "парадигмы" ООП нарушаются.

Автор: bsa 16.10.2013, 17:26
http://forum.vingrad.ru/index.php?show_type=forum&showtopic=370278&hl=%D0%B2%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D0%AB%D0%B9+%D0%B4%D0%B5%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D0%BE%D1%80

Автор: azesmcar 16.10.2013, 18:14
Цитата(zzkoderzzzx @  16.10.2013,  16:58 Найти цитируемый пост)
не ОО код значит плохой код

кто так решил? расскажи это Степанову smile 

Автор: baldina 16.10.2013, 19:06
Цитата(zzkoderzzzx @  16.10.2013,  16:40 Найти цитируемый пост)
STL ...  нарушает все парадигмы ООП

с этого места поподробнее, что именно нарушается

Цитата(zzkoderzzzx @  16.10.2013,  16:40 Найти цитируемый пост)
В настоящих ОО-языках

определение настоящего ООЯ в студию плиз

Цитата(zzkoderzzzx @  16.10.2013,  16:58 Найти цитируемый пост)
не ОО код значит плохой код

расскажите это Кнуту и Вирту

Деструктор должен быть виртуальным, если предполагается (позволяется) наследование.
Даже при "чиста ОО" подходе далеко не все классы должны иметь наследников.
С++ мультипарадигмный язык, в нем необязателен тезис "все есть объект", так что делать все деструкторы виртуальными неразумно.

Автор: kemiisto 16.10.2013, 19:08
Можно было бы сразу призвать в этот топик санитаров, но пойдём более конструктивным путём. smile 

Откуда, уважаемый, дровишки? Вы где всего этого, мягко скажем, бреда поначитались?

Нам бы знать, так сказать, на будущее.

Автор: zzkoderzzzx 16.10.2013, 19:32
Цитата(vinter @ 16.10.2013,  17:24)
О как. Давай-ка по пунктам, на примере std::vector, расскажи какие-такие "парадигмы" ООП нарушаются.

1. protected члены-данные нарушают принцип инкапсуляции в классах-наследниках
2. нельзя полноценно наследовать классы от vector за счет невиртуального деструктора
3. нет виртуальных методов, а следовательно и полиморфизма

Основные 3 принципа ООП нарушены.
 
Можно добавить замечание про код с макросами, бессмысленными названиями, чрезмерным использованием символа _ (часто встречается даже __ ). 
Такой код практически нигде не пройдет code review .

Автор: azesmcar 16.10.2013, 19:36
Цитата(zzkoderzzzx @  16.10.2013,  19:32 Найти цитируемый пост)
2. нельзя полноценно наследовать классы от vector за счет невиртуального деструктора

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

Цитата(zzkoderzzzx @  16.10.2013,  19:32 Найти цитируемый пост)
3. нет виртуальных методов, а следовательно и полиморфизма

Открою тебе секрет. Весь STL построен на полиморфизме smile 
Полиморфизм это не виртуальные функции. Виртуальные функции всего лишь один из методов для реализации динамического полиморфизма.

Автор: vinter 16.10.2013, 20:18
zzkoderzzzx, дело в том, что не каждый объект  является промежуточным звеном, есть и конечные звенья. Поэтому не каждый объект должен быть базой для другого объекта и это не нарушает принципы ОО нисколько. Полиморфизм и наследование не являются обязательным атрибутом объекта, а, скорее, языка на котором можно или нельзя описать объект с точки зрения ООП. Насчёт protected я, частично, согласен. Это ослабление правил, но и ООП не доктрина ;)

Цитата

Можно добавить замечание про код с макросами, бессмысленными названиями, чрезмерным использованием символа _ (часто встречается даже __ ). 

Всё это сделано сознательно, т.к. для разработчиков библиотек зарезервированы имена типа __Upper*. Они не являются частью интерфейса, а значит не могу рассматриваться в контексте какой бы то ни было парадигмы.

Автор: zzkoderzzzx 16.10.2013, 20:24
Цитата(vinter @ 16.10.2013,  20:18)
Всё это сделано сознательно, т.к. для разработчиков библиотек зарезервированы имена типа __Upper*. Они не являются частью интерфейса, а значит не могу рассматриваться в контексте какой бы то ни было парадигмы.

Это сказано не про парадигмы ООП, а про общее качество кода. Такой стиль не удовлетворяет Microsoft coding standard, а также стандартам кодирования, принятым в других организациях.

Автор: zzkoderzzzx 16.10.2013, 21:06
Цитата(azesmcar @ 16.10.2013,  18:14)
Цитата(zzkoderzzzx @  16.10.2013,  16:58 Найти цитируемый пост)
не ОО код значит плохой код

кто так решил? расскажи это Степанову smile

Вот например статья на эту тему
http://forum.sources.ru/index.php?showtopic=293695

Автор: akizelokro 16.10.2013, 22:07
Неочевидно, даже близко (и не прочитав статью).
ООП не более чем шаг к индустрии, и должен рассматриваться только с этой точки зрения. В рамках этого шага.
Если же переходить ab ovo, то всё это лишь подвид математических вычислений. И если применимы понятия "плохой" и "хороший" с точки зрения эстетики, то там определяется всё логикой и математическими "привычками".

Автор: baldina 16.10.2013, 22:32
Цитата(zzkoderzzzx @  16.10.2013,  19:32 Найти цитируемый пост)
Такой код практически нигде не пройдет code review

а где именно? давайте посмотрим им в лицо - мужественным людям, отказавшимся от STL (кстати, что они используют,  не MFC ли?)

Цитата(zzkoderzzzx @  16.10.2013,  20:24 Найти цитируемый пост)
Такой стиль не удовлетворяет Microsoft coding standard

это ты про дефайны? загляни в стандартные мелкософтовские заголовки... или они самим себе запрещают свои заголовки использовать?

Цитата(zzkoderzzzx @  16.10.2013,  21:06 Найти цитируемый пост)
Вот например статья на эту тему

забор, да еще многабукф. но принципа ради поискал, где сказано, что не ОО это плохо. не нашел.

Автор: azesmcar 16.10.2013, 23:20
Цитата(zzkoderzzzx @ 16.10.2013,  21:06)
Цитата(azesmcar @ 16.10.2013,  18:14)
Цитата(zzkoderzzzx @  16.10.2013,  16:58 Найти цитируемый пост)
не ОО код значит плохой код

кто так решил? расскажи это Степанову smile

Вот например статья на эту тему
http://forum.sources.ru/index.php?showtopic=293695

Во первых давайте четко различать авторитетную литературу и написанное на заборе. Покажи авторитетный источник информации а не статью никому неизвестного автора.
Тот же Степанов, создатель stl и generic программиривания, вообще не признает объектно-ориентировааный подход
Цитата

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all. I find OOP methodologically wrong

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

Добавлено через 2 минуты и 29 секунд
По поводу стиля с подчеркиваниями: это зарезервированные имена как уже заметили выше, а неоправданных макросов в стл я не припомню.

Добавлено через 3 минуты и 9 секунд
Цитата(baldina @  16.10.2013,  22:32 Найти цитируемый пост)
забор, да еще многабукф. но принципа ради поискал, где сказано, что не ОО это плохо. не нашел

Я тоже кстати не нашел smile

Добавлено через 5 минут и 13 секунд
Цитата(zzkoderzzzx @  16.10.2013,  20:24 Найти цитируемый пост)
Такой стиль не удовлетворяет Microsoft coding standard, а также стандартам кодирования, принятым в других организациях.

Интересно а реализация стл поставляемая с visual studio тоже не пройдет у н х ревью? smile 

Автор: codemonkeys 17.10.2013, 08:45
Цитата(baldina @ 16.10.2013,  22:32)
Цитата(zzkoderzzzx @  16.10.2013,  21:06 Найти цитируемый пост)
Вот например статья на эту тему

забор, да еще многабукф. но принципа ради поискал, где сказано, что не ОО это плохо. не нашел.

Там сказано хороший код это ОО код.
Значит не ОО код - плохой.

Добавлено через 6 минут и 11 секунд
Цитата(azesmcar @ 16.10.2013,  23:20)
Интересно а реализация стл поставляемая с visual studio тоже не пройдет у н х ревью? smile

По идее не должна пройти, но как то прошла. Индусам видимо было в лом писать свой СТЛ, и они взяли опенсорс реализацию без кодревью : вроде работает и х** с ним.

Автор: bsa 17.10.2013, 10:21
Цитата(codemonkeys @  17.10.2013,  09:45 Найти цитируемый пост)
Там сказано хороший код это ОО код.
Значит не ОО код - плохой.
Качество кода определяется несколько иначе. И ОО тут играет весьма посредственную роль.

Автор: azesmcar 17.10.2013, 10:48
Цитата(codemonkeys @  17.10.2013,  08:45 Найти цитируемый пост)
Там сказано хороший код это ОО код.

Я все не прочитал, но по моему там написано, что ОО код - это хороший код. А это не тоже самое, что хороший код - ОО код.
Mercedes - хорошая машина, но хорошая машина не обязательно только Mercedes. Аналогия понятна. Тем не менее я уверен, что найдешь кучу статей в интернете написанных на форумах и в блогах о том, что ООП - класс, все остальное отстой smile
Я же говорю о том, что для доказательства надо оперировать материалом авторов, пользующимся авторитетом в мире программирования, а не ссылками на блоги никому неизвестных авторов.
Тот же boost не имеет ничего общего с OOP, но тем не менее
Цитата(Herb Sutter and Andrei Alexandrescu @  C++ Coding Standards)

...one of the most highly regarded and expertly designed C++ library projects in the world.


Автор: VSB 19.10.2013, 00:00
Цитата(codemonkeys @  17.10.2013,  08:45 Найти цитируемый пост)
По идее не должна пройти, но как то прошла. Индусам видимо было в лом писать свой СТЛ, и они взяли опенсорс реализацию без кодревью : вроде работает и х** с ним.


Ошибаетесь
Изначально код STL был куплен у Dinkumware, сейчас он пишется в самой MS, и его мейнтейнер - Stephan T. Lavavej

Автор: Zadnica 21.10.2013, 08:22
Цитата(VSB @ 19.10.2013,  00:00)
Цитата(codemonkeys @  17.10.2013,  08:45 Найти цитируемый пост)
По идее не должна пройти, но как то прошла. Индусам видимо было в лом писать свой СТЛ, и они взяли опенсорс реализацию без кодревью : вроде работает и х** с ним.


Ошибаетесь
Изначально код STL был куплен у Dinkumware, сейчас он пишется в самой MS, и его мейнтейнер - Stephan T. Lavavej

Сути это не меняет. Купили код у какой то г*вноконторы, поэтому он такой х*ёвый.

Добавлено через 12 минут и 53 секунды
Цитата(azesmcar @ 16.10.2013,  19:36)
Открою тебе секрет. Весь STL построен на полиморфизме smile 
Полиморфизм это не виртуальные функции. Виртуальные функции всего лишь один из методов для реализации динамического полиморфизма.

Не смеши. 

В STL и нормального наследования то нет -иерархии не больше 3 классов, не говоря о множественном наследовании, о полиморфизме и речи не идет.

Автор: baldina 21.10.2013, 10:10
Цитата(Zadnica @  21.10.2013,  08:22 Найти цитируемый пост)
В STL ... полиморфизме и речи не идет. 

Zadnica, может сначала http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D0%B8%D0%BC%D0%BE%D1%80%D1%84%D0%B8%D0%B7%D0%BC_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)?
полиморфизм разный бывает. чего нет в шаблонах С++, так это полиморфизма подтипов (видимо в угоду простоте концепции и скорости компиляции), хотя вполне могли бы быть в виде http://en.wikipedia.org/wiki/Concepts_(C++). Вероятно http://www.stroustrup.com/C++11FAQ.html#what-concepts.

Автор: azesmcar 21.10.2013, 10:37
Zadnica,

Почитай для начала что такое полиморфизм.

Автор: Zadnica 21.10.2013, 11:00
Шаблоны не истинный ОО-полиморфизм,  это всего лишь обёртка над макросами С.

Автор: baldina 21.10.2013, 11:52
Цитата(Zadnica @  21.10.2013,  11:00 Найти цитируемый пост)
истинный ОО-полиморфизм

это не истинный ОО-полиморфизм, а всего лишь обёртка над ассемблером. 

Цитата(Zadnica @  21.10.2013,  11:00 Найти цитируемый пост)
Шаблоны ... всего лишь обёртка над макросами С. 

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)