Я создаю класс-наследник от map<key,value>



В качестве value идут указатели на объекты.
Кстати говоря по ходу вопрос: map::clear() не будет уничтожать эти объекты?  (В деструкторе стоит цикл c delete объектов второго параметра)

Пускай имеется Dictionary<int, MyObject*> m_dict c записями.
Когда я выполняю присваивание 
Dictionary<int, MyObject*> m_dict1=m_dict, все указатели второго параметра шаблона копируются.  Таким образом, если разрушается m_dict1, то разрушаются объекты и в m_dict.  А это плохо.
Может нужно перегрузить copy конструктор Dictionary и там попытаться по новому проинициализировать каждый объект, надеюсь, что они также имеют copy конструкторы?
Где я чего не понимаю.

umlprog, используйте shared_ptr

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

Сомневаюсь. Иначе vector< int > бы не работало 

Эммм... Походу глупость сморозил...
Попробую реабилитироваться  ...

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

JackYF, теплее  ?

Gluttton, зачем он там? тип должен быть Copyable, а как это происходит - не важно

ОК... Лучше помолчу...

А можно обойтись без boost?
(Вот как C# людей портит!  )

Есть способ динамически создать объект как



но для этого кажеться, класс должен содержать DECLARE_DYNAMIC макрос, чего ожидать от пользовательского класса не приходится в 100% случаях.  Еще и от CObject нужно унаследоваться.

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

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

Добавлено через 6 минут и 12 секунд
P.S. наследование в том числе и приватное от стл контейнеров не рекомендовано. 


Я так понимаю хранить Вы хотите в мапе сами объекты, и скорей всего полиморфно,
тогда лучше всего сделать класс-враппер, который будет отвечать за хранение и правильное полиморфное копирование (читать про Clone)
т.е. что то типа map<int, ObjectHolder> 

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

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

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



Это сообщение отредактировал(а) umlprog - 16.5.2010, 21:01

потому что они логически законченные..



перегружать и не нужно.. 




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


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

Это не ответ.


Уникальные у вас чувства: у других форумчан таких не возникло.


Разве три несчастные строчки вызывают затруднение?

У других форумчан они вызвали более законченные чувства, после которых им (форумчанам) читать дальше и декодировать Ваши вопросы расхотелось    
Вы не заметили, что ответы закончились?   

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

Для этого используют включение, а не наследование (что кстати и рекомендуется для stl контейнеров)

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