Не раз слышал, что наследоваться от STL-классов - не есть хорошо, однако доходчивого объяснения с конкретными примерами не видел ( я не говорю, что их нет - просто не видел  ). Все объяснения сводятся к тому, что они (STL-классы) не предназначены для этого, но, согласитесь, что это - довольно общее объяснение, и не говорит почему же именно они не предназначены.
Например, что плохого будет, если я наследуюсь от deque и добавлю туда некоторый функционал

Спасибо за конкретные объяснения. Хотя... за любые - тоже спасибо 

именно в этих функциях ничего страшного нет: они бесполезны, т.к. не расширяют семантику класса.
а как только захочется создать действительно специализированную версию контейнера (путем наследования), начнутся проблемы: стандартные контейнеры не являются абстрактными классами с точки зрения языка: виртуальные функции использовать нельзя (деструктор не виртуальный), и функции доступа не виртуальные
с другой стороны, стандартные контейнеры являются АТД, и в этом смысле их расширять не требуется.
с третьей: если, скажем, нужно создать стек на основе списка, заимствуя при этом часть функций, технически удобно использовать наследование, но - закрытое. т.е. применить прием С++, не относящийся к ООП. 
еще пример: паттерны типа Facade и Adapter(Wrapper) решаются путем агрегирования или закрытого наследования, а полученный класс также не предназначен для наследования

Добавлено через 6 минут и 7 секунд
тут главное: класс не предназначен для наследования, если его деструктор не виртуальный.
у контейнеров stl так и есть
авторы stl не рассчитывали, что кто-то будет наследовать. получается то же самое, как забивать гвозди разводным ключом: вроде ниче страшного, но как-то непрофессионально. а много гвоздей - еще и неэффективно

Это сообщение отредактировал(а) baldina - 17.2.2011, 18:49

borisbn

Давай подумаем: класс deque не предназначен для наследования, значит

• у него нет виртуального деструктора
• у него нет виртуальных функций, которые можно переопределить
• он не предоставляет protected интерфейса

что в таком случае дает нам наследование? возможность добавления новых функций на основе public интерфейса этого класса?
Да, но зачем это нужно? Все, что можно написать на основе public интерфейса, может быть написано вне класса. std::string известен, как плохо спроектированный класс потому, что в нем слишком много ненужных функций, которые могли вполне быть внешними.
Например функция empty() вполне могла быть реализована вот так

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

Плохого ничего не будет, просто наследования надо избегать, если оно не нужно.

Это сообщение отредактировал(а) azesmcar - 17.2.2011, 19:01

этим, хотя фактически и не нарушаете финальность класса, создаете себе ряд проблем... 
1. функции принимающие вашу деку, не будут принимать стандартную
2. пр замене контейнера, на альтернативный его придется также наследовать... 
3. запутывание стороннего программиста лишней сущностью
4...
всех этих и многих других проблем не будет, если вместо наследования, вы будете использовать свободные функции.. 


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

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

Цитата(baldina @  17.2.2011,  17:38 )

а мне казалось я где-то видел закрытое наследование...

ага, где то было, тоже не помню где именно..



Это сообщение отредактировал(а) mes - 17.2.2011, 19:28

Ну тогда и об остальном поговорим  

Функция подобная функции take_front нарушает принцип одна функция - одна задача.
Далее как следствие
№1

№2

код №1 и №2 НЕ эквивалентны. Хотя делают они по сути одно и тоже, но здесь есть один маленький нюанс.
При возвращении T по значению вызывается копирующий конструктор, который может сгенерировать исключение. В коде №1 мы потеряем элемент, во втором коде - нет. Хотя такой вариант конечно необходим, если нужно сделать операцию атомарной.

Это сообщение отредактировал(а) azesmcar - 17.2.2011, 19:43

может. бесспорно. однако может и должно - разные вещи. помему всё-таки должно ?

мягко говоря не очень понимаю почему. Мне например очень нравится Qt. Там этот принцип явно не соблюдается


почему???


чевойта © Интерны? да, новые функции не будут видны, но функционал deque, как базового класса - будет


Мейерс, ессно, авторитет, однако, я должен не принять, а понять 

Добавлено через 7 минут и 15 секунд
кстати о Qt, есть там хороший класс QDir. У него есть ф-ция entryList (или как-то так). В возвращаемом списке - имена файлов или подкаталогов из каталога, который "обслуживает" этот самый QDir. Но... они все относительные, поэтому, чтобы получить список файлов с полными именами можно либо написать свободную ф-цию

либо наследоваться от QDir и добавить ф-цию

объясните, пожалуйста, чем первый вариант лучше второго ?

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


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


Интересный вопрос.

Зачем надо избегать использовать то, что не нужно...  
Ну вообще это зависимости, их надо избегать. Наследование - тесная связь, самая тесная после дружбы.

Посмотри в книге "Новые сложные задачи на C++ Герба Саттера", глава 37, Ослабленная монолитность std::string.


Это сообщение отредактировал(а) azesmcar - 17.2.2011, 20:49

azesmcar, я правильно понимаю, что единственным аргументом (во всяком случае чётко сформулированным) является наличие тесной связи (зависимостей), которые 1) замедляют компиляцию 2) принуждают тянуть за собой набор h-ников
и всё ?

в принципе - тоже аргумент, но IMHO не решающий

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

Посмотри в книгу, о которой я писал. Там 4 главы, всего не перескажешь.  

Это сообщение отредактировал(а) azesmcar - 17.2.2011, 20:54

azesmcar, то, что оно не нужно, сказали вы, соответственно ответ на вопрос почему - потому, что не нужно - рекурсия  IMHO

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

читал и не раз, но, т.к. не нашёл там понятных (для меня, ессно) объяснений, поэтому и обратился на форум

ну...не нужно, потому-что это ничего не дает.  

хорошо, вот Вы скажите (я не знаю Qt, потому давайте вернемся к STL  ) чем функция empty() в виде метода лучше, чем в виде свободной функции? Допустим у нас есть классы vector, list и string и какой-то молодой специалист забыл добавить в них функцию empty(). Ваши действия.

Расширение класса по средствам наследования vs свободная функция.

Ваш выбор (аргументированный естественно).


Это сообщение отредактировал(а) azesmcar - 17.2.2011, 20:58

абсолютно ничем, однако в нескольких источниках ( azesmcar, Мейерс  ) утверждается, что свободные ф-ции лучше, а я и не могу понять почему... почему лучше ? почему не поставить их на одну полку ?



  

borisbn

Ну..может молодой специалист решил реализовать STL, а функцию empty забыл..например в нашей компании один мужик (видимо очень важный, так-как его до моего появления все еще не уволили) решил, что компании позарез необходим свой класс string, так-как STL-овский неудачен..в нем видите ли мало функций  

так у нас появился свой класс string (наследник std::string естественно, с нуля написать у него бы мозгов не хватило), в котором были функции (приготовьтесь, это не шутка)

в общем..не отвлекаемся....


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

и Вы можете сказать, что свободная функция не лучше?

получается как-то, что я отстаиваю наследование, хотя это не так. я просто хочу разобраться...
azesmcar, в вашем примере чем такое

лучше, чем


честно говоря, перечитал - из пальца высосано, но....... то ли пример - не очень, то ли я уже спать хочу 







жесть... не верю 

Конкретно это я писал в ответ на вопрос, почему свободные функции предпочтительнее методов и чем плохи монолитные классы. 
Давайте углубимся в детали. Программист написал функцию метод, работающую для контейнера vector. Функция работает используя итераторы. Теперь мне тоже необходима эта функция и мне придется дублировать код, хотя этот код мог быть написан в виде свободной функции и использоваться для каждого контейнера (хороший пример алгоритмы STL).

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

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

я бы показал, там еще много смешного, но я оттуда 4 года назад уволился  
причем писал не индус какой нибудь, а американец, с высшим американским образованием.  

Вы явно упускаете все, что Вам уже не одним постом пытаются объяснить..
скорость компиляции и тяга это все все мелкие проблемы..  самая главная проблема в напряжении мозга наличием лишних сущностей.. 
все остальное ерунда.. 
если в программа основанна на уже упомянутом классе string, то пусть будет что угодно, хоть "format c: "
но если Вы хотите строить из удобных кирпичиков, которые не нужно три дня шлифовать, прежде чем состыковать, 
и иметь такую стену, в которой при замене кирпича на другой аналогичный не нужно заново перебирать всю постройку, то тогда думаю стоит обратить более пристальное внимание на советы, приведенные выше... 

Мы тут говорим о двух моментах одновременно и все запутывается. Давайте разберемся.

имеем два утверждения.

1. класс не должен быть монолитным и должен предоставлять минимально возможный интерфейс. Остальные функции, которые можно написать на основе public интерфейса класса должны быть свободными.
2. не надо наследовать класс, если это НЕ необходимо.

Первый пункт возник из за приведенного ТС примера. По первому пункту все есть еще разногласия?

Это сообщение отредактировал(а) azesmcar - 17.2.2011, 22:35

azesmcar, первый вопрос менее очевидный

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

попробую ещё с двух сторон взгляд предоставить
(вообще-то думал с одной, но пока писал, увидел вторую )

1. с точки зрения пользователя дополнительной функциональности
Код, написанный в take_front, по сути, подходит для любого deque, однако он требует чтобы объект был именно типа MyDeque. Как объяснить пользователю (другому программисту) какими причинами руководствовался разработчик, когда добавлял такое ограничение? Чего ради?

2. с точки зрения разработчика дополнительной функциональности
Наследование, как способ расширения функциональности, не очень хорошо масштабируется.

Например, есть у нас std::deque.
Класс хороший, но кому-то не нравится, что там нет функции remove_first_half_of_elements. Решение простое - наследуем класс, добавляем метод.

Другому программисту не нравится, что нет функции duplicate_all_elements. Решение простое - наследуем класс, добавляем метод.

Третьему программисту захотелось и того, и того. Решение очевидное - множественное наследование (ну не писать же код заново). Сразу же выясняется, что наследование от std::deque не виртуальное, нужно править код.

Каждая новая комбинация желаемой функциональности - новый класс (т.е. количество классов экспоненциально растёт). Альтернатива - создать один класс, в который впихнуть все расширения. Теперь у пользователей нет возможности не зависеть от новой функциональности, которая (потенциально) тянет за собой кучу других ненужных зависимостей...

Сравним с внешними функциями: хочешь функцию - подключай h-файл и пользуйся. Тянет какие-то зависимости - подключай и тягай с собой дополнительные библиотеки. Но только для той функциональности, которая тебе реально нужна. Не больше. Красота 

Это сообщение отредактировал(а) maxim1000 - 17.2.2011, 23:59

maxim1000, да, это похоже на правду жизни
в некоторых проектах постоянное добавление функциональности приводит к появлению глубокой иерархией в этак > 10 классов, перемежая с множественным наследованием ( обязательно где-нибудь встретится повторное наследование  )
этакий архитектурный коллапс

Это сообщение отредактировал(а) alexvs11 - 18.2.2011, 00:11

Ну и темка разрослась, по неосторожно брошенному мной вчера слову.
Спасибо всем, почитал с удовольствием.
А вообще, мое мнение такое. Если программер точно знает что делает, то на здоровье! Страуструп, например, где-то наследуется в своей книге от вектора. 
Ну ему можно (так же как и всем кто досконально понимает, что делает).
Сам я от стл никогда не наследуюсь. Так как далеко мне еще до глубокого понимания механизмов...
А вот goto, например, иногда применяю. И плевать, что там подумают. Есть случаи когда это оправдано.
так-же и здесь, вероятно есть случаи когда стоит нарушить правила. 
Но до этого нужно сначала дорости.

То было private наследование.

Один раз писал алгоритм и казалось вот он тот случай, мне нужен goto! Порадовался, но сделал с помощью switch.  



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

и



Это сообщение отредактировал(а) azesmcar - 18.2.2011, 06:13

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


это то ясно, не первый раз замужем 
Понимаете, я поднял тему вовсе не потому, что защищаю наследование от STL-классов, а потому, что внятного объяснения почему это плохо не видел. Впрочем также, как и использование goto, что не значит, что я буду говорить направо и налево: "использование goto - хорошо".

ok, всем большущее спасибо. закрываю "для галочки", но мониторить буду, так, что, если есть ещё мысли/идеи - welcome 

это не плохо   , просто "любой" другой вариант в общем случае лучше  

Добавлено через 39 секунд
а если есть лучшее, то зачем создавать себе лишние неудобства ?.. 

Добавлено через 1 минуту и 32 секунды
а так любое решение - плохое, но из двух зол принято выбирать меньшее © 

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

  
Да, но смысл явно здесь затуманен. Первый свитч вообще не понятно зачем. Некоторые для этой же цели любят применять
do{...; break; ...}while(0); лишь бы не применять goto. Зачем такие ухищрения? С goto было бы ясней. . А чем ясней, тем лучше.

volatile, если приведете пример с goto, который будет структурно ясней, "заработаете" +1 в репу   

Ну, собственно само напрашивается...
(просто убрал первый свитч, с ненужными case'ми который, имхо, и затуманивает дело.)

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


применительно к этой задачи он, имхо, удачнее подходит, чем goto или switch..

Это сообщение отредактировал(а) mes - 19.2.2011, 01:34

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

задавался подобным вопросом, возможно на этом форуме, не помню.. но, как результат, все равно реализую string_list и string_vector унаследовав list или vector соответственно. ничего плохого в этом нет.

Добавлено через 58 секунд
goto - да. сложно представить ситуацию, когда он нужен. в жизни такой надобности не встречал в с++.

volatile
Ну вообще-то goto здесь не так напрашивался. В твоем примере goto вообще непонятно зачем нужен.
Я вот это имел ввиду.

Хотя второй switch любой уважающий себя компилятор и преобразует в таблицу переходов, первая часть все таки имеет небольшой overhead при инкрементировании счетчика. Так-что с goto выйдет чуточку быстрее.
Несмотря на то, что я сделал через switch, я думаю это хороший пример, когда goto действительно является неплохим решением.

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

чем это лучше будет std::list<std::string> > и std::vector<std::string> >
одновременное наследование в этом случае этож ужостъ, хотя бы по колву одинаковых методов в обоих классах

Добавлено через 1 минуту и 30 секунд
уж что угодно лучше было бы агрегировать std::list<std::string> или наследовать в новый класс

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

все-таки все немного глубже. 
1. если программа будет развиваться, сопровождаться и т.д., уменьшение связей (зависимостей) упростит жизнь.
2. наследование (по сравнению со свободной функцией) носит более специфический характер, т.к. не просто решает еще одну задачу, а является результатом проектных обобщений.
3. самовоспитание. если привыкнуть что-то делать правильно, меньше надо будет напрягаться в случаях, когда "делать правильно" следует обязательно

 , я в курсе.. и я не противник goto, но сторонник применения альтернативных и не "очевидных" методов..
П.С. если идут на пользу, а не просто потому что "где-то увидел что так надо"..    


ну это уже извращение, по воробьям из пушки.. 


  

P.S. "правильно" - это значит создавать как можно меньше потенциальных проблем 

  А я использую, причем часто генерю строковое исключение (LPCWSTR) . Удобно можно сразу текст ошибки указать. Либо исключение с кодом. На сегодняшний день это нормально. Даже lexical_cast<> генерит как результат неуспеха.

ммм.. только вот как связано "результат неуспеха" и "выход из вложенного цикла" ?!
  

azesmcar, ну первый свитч сбивает с толку просто.
Ну и mes сказал чтобы с гото было.   
Я бы это вообще вот так написал.

Хотя это все дело вкуса, конечно.

mes, ну досрочный выход из вложенного цикла это часто какой-то результат. Положительный или отрицательный. Исключение это не обязательно крах. Это вполне может быть отрицательный результат проверки. Иногда удобно положительный результат выводить как исключение. 

а если мьютексов 10?

ну в примере 5 было. В любом случае с десятью goto тоже не шоколадно.
Если десять, двадцать и более, вероятно сделала бы что-то типа небольшого класса, включающего указатель на мьютекс.
в конструкторе try_lock(), в деструкторе, еслио золочен unlock();


Это сообщение отредактировал(а) volatile - 20.2.2011, 16:27

да это не крах.. исключение это не отрицательный, а непредвиденный случай проверки  

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

  

исключения С++ слишком медленные, чтобы использовать их иначе кроме как в исключительных ситуациях.

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

но чем return не угодил ?!

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

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

ну приз заслужили,  вполне конкурентноспособный вариант.. 

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

чем RAII не угодил ?

volatile

Ну как раз вот этой "елочки" я и пытался избежать 

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

присойденяюсь к вопросу.

  Так речь не только о освобождении ресурсов, возможно требуется изменить состояние нескольких объектов. Это может быть объект ядра системы.

Alexeis

Мне все равно непонятно. Хотелось бы посмотреть на пример, где по твоему кидать исключение вместо return является хорошим решением.

Это сообщение отредактировал(а) Abyx - 21.2.2011, 11:19

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

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

Alexeis, там надо еще больше сущностей. Твоя функция слишком много знает и умеет.

Alexeis, спасибо за код.. все стало ясно..  
согласен, если писать на С++ не С++-код, то и исключения пригождаются...
 

Это сообщение отредактировал(а) mes - 21.2.2011, 15:42

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

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

mes, thx