у меня некоторое время уже пишется немелкая прога
и лишь сравнительно недавно я начал использовать boost::shared_ptr

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



а вот теперь, как я понял преимущества shared_ptr, функции типа Func1 стали принимать shared_ptr'ы. И получилась ситуация:


как бы это можно провернуть, чтобы работало?

Это сообщение отредактировал(а) Alek86 - 12.11.2007, 19:49

Передаёшь локальную переменную, она уничтожается сейчас же, не гуд.





возможно, 

в реале все чуток сложнее
 к примеру, так:


выход вижу в том, чтобы хранить рядом с

еще и 


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

Добавлено @ 21:34
Fazil6, так бы я догадался, но дело в том, что код старый и работает - не хочется его весь менять

Добавлено через 3 минуты и 32 секунды
а, да, еще его МНОГО

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

зачем указатель передавать по ссылке?

Это сообщение отредактировал(а) Alek86 - 12.11.2007, 21:34

это так, на пробу. Возможно, и незачем.

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


заменить на

дальше компилятор скажет где исправить (выкинуть delete и в аргументах). Использование m_MyClass как указателя никак не изменится с изменением на shared_ptr
Но, если стоит выбор между альтернативами, нужно остановиться на чем-то одном. На 2-х стульях тяжело усидеть.

неужели так мало у кого такие проблемы возникали, что при проектировании shared_ptr не учли возможность такой поддержки старого кода? :(

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


ППКС.

?



  
это скажи Страуструпу 
вообще весь С++ на том и держится, что старый код менять сильно не нужно

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


какой такой? Чтобы деструктор shared_ptr не вызывал delete ? Нахрен он тогда нужен?
Все, что надо там учли.

Если старая функция не сохраняет указатель на объект и не пытается его удалить, то можно ее оставить до поры до времени. Но если старая ф-я гденибудь сохранит указатель на объект, то возможна ситуация когда этот указатель проживет дольше чем все shared_ptr-ы на тот-же объект и если программа попробует к нему обратица, то будет AV (aka segfault). Так-что как уже здесь не раз сказали проще исправить все функции.
До использования shared_ptr я использовал свой велосипед, базовый класс поддерживал подсчет ссылок, а его  деструктор был защищенным. Благодаря этому нельзя было создать такой объект в стеке. Класс указателя который работал с моим указателем был объявлен другом, короче в результате работать с такими объектами возможно только через мою версию смарт-поинтера, и это спасало от многих ошибок

Извините, если прерву ваш спор ни о чём, но изначальная проблема решается элементарно - достаточно взглянуть на описание класса shared_ptr(можно даже не читать - просто взглянуть).

гы, пепец я внимательный 
спасибо

Кстати, если уж часто этим пользоваться, то я бы сделал так:

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

есть стандартный функтор, что ничего не делает?

Добавлено через 1 минуту и 39 секунд
ЗЫ. скорее всего нету, но "а вдруг?"