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

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


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


весь STL

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

Добавлено @ 16:41

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

Это сообщение отредактировал(а) zzkoderzzzx - 16.10.2013, 16:42

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


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

Это сообщение отредактировал(а) azesmcar - 16.10.2013, 16:57

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

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

Это сообщение отредактировал(а) zzkoderzzzx - 16.10.2013, 16:59

охлол

  По какому поводу обострение? Опять не прошёл собеседование из-за проблем с плюсами?

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

Это сообщение отредактировал(а) vinter - 16.10.2013, 17:24

Схожая тема

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

Это сообщение отредактировал(а) azesmcar - 16.10.2013, 18:15

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


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


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

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

Можно было бы сразу призвать в этот топик санитаров, но пойдём более конструктивным путём.  

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

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

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

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

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


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

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


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

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

Это сообщение отредактировал(а) zzkoderzzzx - 16.10.2013, 20:25

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

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

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


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


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

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

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

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

Добавлено через 3 минуты и 9 секунд

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

Добавлено через 5 минут и 13 секунд

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

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

Добавлено через 6 минут и 11 секунд

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

Качество кода определяется несколько иначе. И ОО тут играет весьма посредственную роль.

Я все не прочитал, но по моему там написано, что ОО код - это хороший код. А это не тоже самое, что хороший код - ОО код.
Mercedes - хорошая машина, но хорошая машина не обязательно только Mercedes. Аналогия понятна. Тем не менее я уверен, что найдешь кучу статей в интернете написанных на форумах и в блогах о том, что ООП - класс, все остальное отстой 
Я же говорю о том, что для доказательства надо оперировать материалом авторов, пользующимся авторитетом в мире программирования, а не ссылками на блоги никому неизвестных авторов.
Тот же boost не имеет ничего общего с OOP, но тем не менее

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

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

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

Не смеши. 

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

Zadnica, может сначала поизучать?
полиморфизм разный бывает. чего нет в шаблонах С++, так это полиморфизма подтипов (видимо в угоду простоте концепции и скорости компиляции), хотя вполне могли бы быть в виде концепций. Вероятно скоро будут.

Zadnica,

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

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

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


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