О чём думали дизайнеры STL, создавая в нём единственный тип смартпоинтеров, который при том (что он единственный) нельзя использовать в контейнерах?

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

В идеале я бы хотел вот такого, но из стандартной поставки:

Никак, в STL нет smartpointer-ов. Непонятно в чем вопрос, если ты сам это знаешь, напиши свой shared_ptr, но я бы использовал boost.

И в любом случае в Base нужно определить виртуальный деструктор 

Виртуальный деструктор тут нафик не нужен.

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

Как нет. А auto_ptr?


Вопрос в том, как люди обходятся? Пишут своё? Почему нет в стандартной библиотеке ничего подходящего?

Ну, потому что Стандартная библиотека в нынешнем виде -- это фиксация на бумаге 1998 года, тогда ещё народ, видимо, коллективно не созрел до смартпоинтеров в коллекциях.
А потом дописали буст... Если по каким-то причинам буст не устраивает, надо просто вырезать кусок, ответственный за shared_ptr, и использовать у себя с чистой совестью 

имелось ввиду тех, о которых ты спрашивал. Про auto_ptr ты сам написал, и сам же сказал почему он не подходит.




нет, почему же..люди уже давно используют буст 
boost смело можно считать стандартной библиотекой.
STL писали давно, в нее много чего не вошло.


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

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

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

Это сообщение отредактировал(а) azesmcar - 18.3.2010, 08:46

Ты в этом уверен на 100%? Потому что обычно, когда есть виртуальные методы, виртуальный деструктор нужен. Другими словами, если потомки класса Base имеют хоть один атрибут, то без виртуального диструктора твой первый пример приведет к утечкам памяти.

Напиши свой вариант shared_ptr внутри #ifdef/#else/#endif, что позволит использовать твой код юзая смартпоинтеры нового стандарта лишь задефайнив определенный макрос.

Мне пора в отпуск..

я функцию Do за деструктор принял  

наконец понял о чем речь.


можно сказать он нужен всегда (когда есть виртуальные методы), а тут тем более, иначе в строке

будет UB.
gcc даже warning выдает на классы, у которых есть виртуальные методы и не виртуальный деструктор.

Это сообщение отредактировал(а) azesmcar - 18.3.2010, 11:36

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

Уверен. Что за атрибут? Где тут утечка?

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


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

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

Как тут уже сказали, есть буст и (когда-нибудь "релизнется" же он ) C++0x, в STL которого есть тот самый бустовский умный указатель.

JackYF, в следующем году релизнется:
http://herbsutter.wordpress.com/2010/03/13...ndards-meeting/

Ну так деструктор вызываться должен для того, чтобы что-то в классе удалить/почистить/закрыть/etc., а у меня же класс пустой.

Повторяю еще раз, утечка памяти это частный случай реализации.

а Child1::vf_ptr ?

  

Спасибо за ссылку, но это ещё ничего не значит. Изначально его планировали релизнуть до 2009, и сейчас у них тоже только планы 

Тут два варианта. Либо открытый виртуальный деструктор, если собираемся уничтожать объект по ссылке/указателю базового класса (интерфейса). Либо защищённый невиртуальный деструктор, он не даст этого сделать.

  

так что ли?

так он и этого тоже не позволит

может речь идет о защищенном наследовании? В таком случае совсем непонятно зачем там нужен полиморфизм.

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

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

Добавлено @ 15:45
Конечно не позволит. Подразумевалось что базовый класс абстрактный.

Добавлено @ 15:47
Мне удобнее считать абстракный класс интерфейсом. В C# именно так и сделано, насколько я знаю.

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

Нет, так:


Это сообщение отредактировал(а) Леопольд - 19.3.2010, 15:48

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



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

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

В таком случае, A::~A() должен быть виртуальным... 

нет, просто опечатка, исправил.

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

т.е. по твоему абстрактные классы не нужны?

Тогда я не понял что ты имел ввиду. Разверни, будь добр...

Добавлено @ 16:05
По моему надо стараться избегать помещать данные и не чистые функции в абстрактные классы. По крайней мере мне лично, так проще...

Это сообщение отредактировал(а) Леопольд - 19.3.2010, 16:06

да тоже самое, класс, который не инстанцируется, абстрактный он или нет совершенно не важно.

Где это может понадобиться?

std::unary_function, std::binary_function ...

Точно, это и есть претенденты на protected деструкторы... 

Добавлено через 1 минуту и 19 секунд
Ты меня понял быстрее чем я тебя... 

Ну так, если он всё-таки будет пуст, виртуальный деструктор не нужен?

Если в твоем коде ни один наследник класса без виртуального деструктора не имеет атрибутов, то СКОРЕЕ ВСЕГО утечек памяти не будет. Но... Могут и быть, так как в стандарте прописано, что в этом случае будет НЕОПРЕДЕЛЕННОЕ ПОВЕДЕНИЕ, а оно может зависеть и от компилятора, и от ОС, и от настроек оптимизации, и от положения солнца относительно луны (но последнее уже мало вероятно).

Позвольте узнать на чем Вы, по Вашему мнению, экономите, имея виртуальные функции и не делая деструктор виртуальным ?

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

Тебе совершенно понятно объяснили, что в твоём случае имеет место быть UB и данных, которые ты предоставил недостаточно. Чтобы сказать будет или нет утечка можешь засунуть релиз в дизассемблер и посмотреть, что нагенерил компилятор. Или написать ключевое слово virtual и жить спокойно. 

сделай

а потом добавь

и повтори то же самое

Сделал. И что?

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