| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > Невиртуальный деструктор |
| Автор: zzkoderzzzx 16.10.2013, 15:43 |
| Известно, что надо всегда делать деструктор виртуальным. Тем не менее он не становится виртуальным без участия программиста. Значит разработчиками С++ была предусмотрена ситуация, когда есть необходимость в невиртуальном деструкторе. Какие вы можете привести примеры таких ситуаций? |
| Автор: zzkoderzzzx 16.10.2013, 16:40 | ||||
STL использует классы, но при этом нарушает все парадигмы ООП. Поэтому пример не очень хороший. Добавлено @ 16:41
В настоящих ОО-языках все методы виртуальные. |
| Автор: azesmcar 16.10.2013, 16:57 | ||
что значит нарушает? Код STL вообще не обьектно ориентированный. вызов виртуального метода имеет накладные расходы и далеко не всегда имеет смысл делать функцию виртуальной. все методы виртуальны в Java, но скажем в C# такого нет. |
| Автор: bems 16.10.2013, 16:58 |
да, но далеко не всегда нужно применять ООП |
| Автор: zzkoderzzzx 16.10.2013, 16:58 | ||
не ОО код значит плохой код |
| Автор: bems 16.10.2013, 17:00 |
охлол |
| Автор: NoviceF 16.10.2013, 17:05 |
| |
| Автор: vinter 16.10.2013, 17:24 | ||
О как. Давай-ка по пунктам, на примере 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 |
кто так решил? расскажи это Степанову |
| Автор: baldina 16.10.2013, 19:06 |
с этого места поподробнее, что именно нарушается определение настоящего ООЯ в студию плиз расскажите это Кнуту и Вирту Деструктор должен быть виртуальным, если предполагается (позволяется) наследование. Даже при "чиста ОО" подходе далеко не все классы должны иметь наследников. С++ мультипарадигмный язык, в нем необязателен тезис "все есть объект", так что делать все деструкторы виртуальными неразумно. |
| Автор: kemiisto 16.10.2013, 19:08 |
| Можно было бы сразу призвать в этот топик санитаров, но пойдём более конструктивным путём. Откуда, уважаемый, дровишки? Вы где всего этого, мягко скажем, бреда поначитались? Нам бы знать, так сказать, на будущее. |
| Автор: zzkoderzzzx 16.10.2013, 19:32 | ||
1. protected члены-данные нарушают принцип инкапсуляции в классах-наследниках 2. нельзя полноценно наследовать классы от vector за счет невиртуального деструктора 3. нет виртуальных методов, а следовательно и полиморфизма Основные 3 принципа ООП нарушены. Можно добавить замечание про код с макросами, бессмысленными названиями, чрезмерным использованием символа _ (часто встречается даже __ ). Такой код практически нигде не пройдет code review . |
| Автор: azesmcar 16.10.2013, 19:36 | ||
Нельзя наследоваться потому, что он для этого не предназначен. Неужели ты думаешь, что любой класс предназначен для наследования? Открою тебе секрет. Весь STL построен на полиморфизме Полиморфизм это не виртуальные функции. Виртуальные функции всего лишь один из методов для реализации динамического полиморфизма. |
| Автор: vinter 16.10.2013, 20:18 | ||
zzkoderzzzx, дело в том, что не каждый объект является промежуточным звеном, есть и конечные звенья. Поэтому не каждый объект должен быть базой для другого объекта и это не нарушает принципы ОО нисколько. Полиморфизм и наследование не являются обязательным атрибутом объекта, а, скорее, языка на котором можно или нельзя описать объект с точки зрения ООП. Насчёт protected я, частично, согласен. Это ослабление правил, но и ООП не доктрина ;)
Всё это сделано сознательно, т.к. для разработчиков библиотек зарезервированы имена типа __Upper*. Они не являются частью интерфейса, а значит не могу рассматриваться в контексте какой бы то ни было парадигмы. |
| Автор: zzkoderzzzx 16.10.2013, 20:24 | ||
Это сказано не про парадигмы ООП, а про общее качество кода. Такой стиль не удовлетворяет Microsoft coding standard, а также стандартам кодирования, принятым в других организациях. |
| Автор: zzkoderzzzx 16.10.2013, 21:06 | ||
Вот например статья на эту тему http://forum.sources.ru/index.php?showtopic=293695 |
| Автор: akizelokro 16.10.2013, 22:07 |
| Неочевидно, даже близко (и не прочитав статью). ООП не более чем шаг к индустрии, и должен рассматриваться только с этой точки зрения. В рамках этого шага. Если же переходить ab ovo, то всё это лишь подвид математических вычислений. И если применимы понятия "плохой" и "хороший" с точки зрения эстетики, то там определяется всё логикой и математическими "привычками". |
| Автор: baldina 16.10.2013, 22:32 |
а где именно? давайте посмотрим им в лицо - мужественным людям, отказавшимся от STL (кстати, что они используют, не MFC ли?) это ты про дефайны? загляни в стандартные мелкософтовские заголовки... или они самим себе запрещают свои заголовки использовать? забор, да еще многабукф. но принципа ради поискал, где сказано, что не ОО это плохо. не нашел. |
| Автор: azesmcar 16.10.2013, 23:20 | ||||||||||
Во первых давайте четко различать авторитетную литературу и написанное на заборе. Покажи авторитетный источник информации а не статью никому неизвестного автора. Тот же Степанов, создатель stl и generic программиривания, вообще не признает объектно-ориентировааный подход
Ооп всего лишь одна из методологий и не надо думать, что она единственно верная. Есть и другие подходы и другие мнения на этот счет, причем мнения авторитетных людей подкрепленные опытом и знанием. Добавлено через 2 минуты и 29 секунд По поводу стиля с подчеркиваниями: это зарезервированные имена как уже заметили выше, а неоправданных макросов в стл я не припомню. Добавлено через 3 минуты и 9 секунд
Я тоже кстати не нашел Добавлено через 5 минут и 13 секунд
Интересно а реализация стл поставляемая с visual studio тоже не пройдет у н х ревью? |
| Автор: codemonkeys 17.10.2013, 08:45 | ||||
Там сказано хороший код это ОО код. Значит не ОО код - плохой. Добавлено через 6 минут и 11 секунд
По идее не должна пройти, но как то прошла. Индусам видимо было в лом писать свой СТЛ, и они взяли опенсорс реализацию без кодревью : вроде работает и х** с ним. |
| Автор: bsa 17.10.2013, 10:21 |
| Качество кода определяется несколько иначе. И ОО тут играет весьма посредственную роль. |
| Автор: azesmcar 17.10.2013, 10:48 | ||
Я все не прочитал, но по моему там написано, что ОО код - это хороший код. А это не тоже самое, что хороший код - ОО код. Mercedes - хорошая машина, но хорошая машина не обязательно только Mercedes. Аналогия понятна. Тем не менее я уверен, что найдешь кучу статей в интернете написанных на форумах и в блогах о том, что ООП - класс, все остальное отстой Я же говорю о том, что для доказательства надо оперировать материалом авторов, пользующимся авторитетом в мире программирования, а не ссылками на блоги никому неизвестных авторов. Тот же boost не имеет ничего общего с OOP, но тем не менее
|
| Автор: VSB 19.10.2013, 00:00 | ||
Ошибаетесь Изначально код STL был куплен у Dinkumware, сейчас он пишется в самой MS, и его мейнтейнер - Stephan T. Lavavej |
| Автор: Zadnica 21.10.2013, 08:22 | ||||||
Сути это не меняет. Купили код у какой то г*вноконторы, поэтому он такой х*ёвый. Добавлено через 12 минут и 53 секунды
Не смеши. В STL и нормального наследования то нет -иерархии не больше 3 классов, не говоря о множественном наследовании, о полиморфизме и речи не идет. |
| Автор: baldina 21.10.2013, 10:10 |
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 |
это не истинный ОО-полиморфизм, а всего лишь обёртка над ассемблером. очень мягко говоря у вас весьма вульгарные представления о языке и его реализации |