Встретил в чужом коде непонятную мне логическую конструкцию



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

стандартная практика в асинхронном/многопоточном коде.
т.е. detach`имся от sessions_, в копии вызывается release() для каждого Session, и в тоже самое время, sessions_ может заполняться новыми Session`ами.

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

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

А что, там планировалось асинхронно вызванному деструктору выполнять еще какие-то операции над объектом?  


Мало ли что, может результат copy-paste-а. У нас таких кодов столько, что если каждым озадачиваться...  

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

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

Наверно все таки это "кодоляп" (от "киноляп"). Решил подстраховаться от возможной своей глупости.

Это сообщение отредактировал(а) cupper - 1.6.2011, 08:39

почему нет?


ну тогда хз..

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

что в этом коде необычного?

http://liveworkspace.org/code/741dcee654ae...69bf5c96da8adad

если опустить это:

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

или что?

boostcoder

Разница в том, что в твоем коде объект не будет удаляться, пока с ним работают, так-как shared_ptr будет держать его в живом состоянии, пока поток на него ссылается, а значит работы с удаленном объектом здесь не будет, а если


то закончиться это как ни странно segmentation fault -ом.

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

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

Добавлено через 2 минуты и 27 секунд
но если sessions_ приватный, смысл создания копии в деструкторе все равно не понятен..

cupper, а друзей у него нет?

кстати. очень "интересный" подход. я бы это сделал через swap - операция значительно быстрее, чем две (копирование и очистка).

а держит ли _second_ ссылку/указатель на classX или SessionsMap?

Скорее всего держит.   
Вполне стандартная ситуация, когда какие то объекты [Session] регистрируются (и дерегестрируются) в каком то менеджере [ClassX], и процесс дерегистрации запускается автоматом при удалении объекта [Session] и при этом производятся какие то нетривиальные действия в менеджере [ClassX].
Удаление скопом всего списка зарегистрированных объектов перед разрушением самого менеджера позволит не выполнять этих самых нетривиальных действий, а так же делать вид, что никаких объектов уже в менеджере нет (если эти самые Session при удалении полезут исследовать содержимое ClassX)