Здравствуйте, Hard_Club, Вы писали:
H_C>А чем может быть оправдано добавление стольких лищних кострукций?
Всего три дополнительные строчки, хотя, конечно, тут предполагается, что объекты уникальны с пределах использования библиотеки.
Такой код бывает нужен, если
— используется событийная модель обработки с неизвестным порядком событий;
— время жизни объекта может зависит от стороннего кода ещё одной библиотеки;
— существует сложная зависимость жизни одного объекта от жизни другого.
Здравствуйте, Hard_Club, Вы писали:
H_C>Что делать есть либа требует передачи в функцию raw поинтера и освобождения его в callback — никак его в smart pointer не завернешь.
Моё ИМХО: при передаче указателя в либу меняется владение указателем. Теперь либа отвечает за освобождение памяти. Она и дернет твой колбек в нужный момент. Значит нужно в момент передачи вызвать release() у смартпоинтера и не забивать себе голову.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Hard_Club, Вы писали:
H_C>Что делать есть либа требует передачи в функцию raw поинтера и освобождения его в callback — никак его в smart pointer не завернешь.
В предположении однопоточности либы:
Построить глобальный мап, типа:
H_C>Что делать есть либа требует передачи в функцию raw поинтера и освобождения его в callback — никак его в smart pointer не завернешь.
В boost::intrusive_ptr завернешь
[UPD]
Ну или положить в сам объект shared_ptr на самого себя. При отдаче в либу — устанавливать, при освобождении из либы — делать ему reset.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Hard_Club, Вы писали:
H_C>Что делать есть либа требует передачи в функцию raw поинтера и освобождения его в callback — никак его в smart pointer не завернешь.
Интересный подход, я бы не додумался. А так — очень плохая идея резервировать память в исполняемом модуле, а освобождать в либе и наоборот. Если использовать smart pointer, то именно это и произойдёт.
Здравствуйте, Hard_Club, Вы писали:
H_C>Что делать есть либа требует передачи в функцию raw поинтера и освобождения его в callback — никак его в smart pointer не завернешь.
У тебя есть опасения что либа может забыть вызвать коллбэк для конкретного указателя?
Здравствуйте, Maniacal, Вы писали:
M>Интересный подход, я бы не додумался. А так — очень плохая идея резервировать память в исполняемом модуле, а освобождать в либе и наоборот.
Он не освобождает в либе. Тут как раз создание и удаления происходит именно в коде пользователя либы, т.е. в колбэке и при создании объекта. Это сделано для обхода граблей при разных crt.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Maniacal, Вы писали:
M>>Интересный подход, я бы не додумался. А так — очень плохая идея резервировать память в исполняемом модуле, а освобождать в либе и наоборот. K>Он не освобождает в либе. Тут как раз создание и удаления происходит именно в коде пользователя либы, т.е. в колбэке и при создании объекта. Это сделано для обхода граблей при разных crt.
Я и говорю. Прекрасный подход. А вот если смартпоинтер передавать, то освобождение будет в либе. Это если при передаче сразу release делать.
Здравствуйте, Hard_Club, Вы писали:
H_C>Что делать есть либа требует передачи в функцию raw поинтера и освобождения его в callback — никак его в smart pointer не завернешь.
А можно поинтересоваться, какая сигнатура у caallback, есть ли какой-нибудь opaque или context?
Здравствуйте, Hard_Club, Вы писали:
H_C>Что делать есть либа требует передачи в функцию raw поинтера и освобождения его в callback — никак его в smart pointer не завернешь.
А какой именно по семантике smart-pointer используется (unique, shared etc)? Можно постараться кастомный deleter пристыковать, например.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Hard_Club, Вы писали:
H_C>>А чем может быть оправдано добавление стольких лищних кострукций? BFE>Всего три дополнительные строчки, хотя, конечно, тут предполагается, что объекты уникальны с пределах использования библиотеки.
BFE>Такой код бывает нужен, если BFE>- используется событийная модель обработки с неизвестным порядком событий; BFE>- время жизни объекта может зависит от стороннего кода ещё одной библиотеки; BFE>- существует сложная зависимость жизни одного объекта от жизни другого.
Делал такое на одном проекте, где нужно было железякой управлять через thirdparty dll
Здравствуйте, Kernan, Вы писали:
K>Тут как раз создание и удаления происходит именно в коде пользователя либы, т.е. в колбэке и при создании объекта. Это сделано для обхода граблей при разных crt.
Так может надо было в либе создавать ? Create/Release для каждого объекта, как в WinAPI.