История изменений

У std::shared_ptr есть метод get, который возвращает сырой указатель, который можно кастовать в void*. Разумеется, чтобы никто не освободил память и указатель оставался валидным, shared_ptr должен где-то хранится до того момента, когда callback уже точно не будет вызван.

Либо всё ещё проще - умные указатели это сахар для C++ кода, при вызове C кода делаешь обычный new и передаёшь этот указатель. А при вызове твоего callback, делаешь delete. Это нормально, так как ты в любом случае делаешь ручное освобождение, не важно это удаление из std::list с автоматическим вызовом деструктора shared_ptr или ручной delete. Callback забудут вызвать или ты забудешь внутри callback сделать операцию направленную на освобождение указателя - будет утечка. RAII не работает в этом сценарии. Танцы с оборачниваем утечки в std::list не особо имеют смысла.

Прочитал внимательнее твой пост. Не надо конвертировать итератор в указатель. Нет никаких гарантий, что структура итератора равна по размеру указателю (и скорее всего она больше). То есть итератор в общем случае непредставим в виде void*. Разве что делать new и перемещать итератор в кучу, а потом ему делать delete, но это явный over-engineering. Опять же не проще ли делать new и delete с самим объектом без всяких std::list и итераторов.

У std::shared_ptr есть метод get, который возвращает сырой указатель, который можно кастовать в void*. Разумеется, чтобы никто не освободил память и указатель оставался валидным, shared_ptr должен где-то хранится до того момента, когда callback уже точно не будет вызван.

Либо всё ещё проще - умные указатели это сахар для C++ кода, при вызове C кода делаешь обычный new и передаёшь этот указатель. А при вызове твоего callback, делаешь delete. Это нормально, так как ты в любом случае делаешь ручное освобождение, не важно это удаление из std::list с автоматическим вызовом деструктора shared_ptr или ручной delete. Callback забудут вызвать или ты забудешь внутри callback сделать операцию направленную на освобождение указателя - будет утечка. RAII не работает в этом сценарии. Танцы с оборачниваем утечки в std::list не особо имеют смысла.

Прочитал внимательнее твой пост. Не надо конвертировать итератор в указатель. Нет никаких гарантий, что структура итератора равна по размеру указателю (и скорее всего она не равна). То есть итератор в общем случае непредставим в виде void*. Разве что делать new и перемещать итератор в кучу, а потом ему делать delete, но это явный over-engineering. Опять же не проще ли делать new и delete с самим объектом без всяких std::list и итераторов.

У std::shared_ptr есть метод get, который возвращает сырой указатель, который можно кастовать в void*. Разумеется, чтобы никто не освободил память и указатель оставался валидным, shared_ptr должен где-то хранится до того момента, когда callback уже точно не будет вызван.

Либо всё ещё проще - умные указатели это сахар для C++ кода, при вызове C кода делаешь обычный new и передаёшь этот указатель. А при вызове твоего callback, делаешь delete. Это нормально, так как ты в любом случае делаешь ручное освобождение, не важно это удаление из std::list с автоматическим вызовом деструктора shared_ptr или ручной delete. Callback забудут вызвать или ты забудешь внутри callback сделать операцию направленную на освобождение указателя - будет утечка. RAII не работает в этом сценарии. Танцы с оборачниваем утечки в std::list не особо имеют смысла.

Прочитал внимательнее твой пост. Не надо конвертировать итератор в указатель. Нет никаких гарантий, что структура итератора равна по размеру указателю (и скорее всего она не равна). То есть итератор в общем случае непредставим в виде void*. Разве что делать new и перемещать итератор в кучу, но это явный over-engineering, а потом ему делать delete. Но тогда не проще ли делать new и delete с самим объектом без всяких std::list и итераторов.

У std::shared_ptr есть метод get, который возвращает сырой указатель, который можно кастовать в void*. Разумеется, чтобы никто не освободил память и указатель оставался валидным, shared_ptr должен где-то хранится до того момента, когда callback уже точно не будет вызван.

Либо всё ещё проще - умные указатели это сахар для C++ кода, при вызове C кода делаешь обычный new и передаёшь этот указатель. А при вызове твоего callback, делаешь delete. Это нормально, так как ты в любом случае делаешь ручное освобождение, не важно это удаление из std::list с автоматическим вызовом деструктора shared_ptr или ручной delete. Callback забудут вызвать или ты забудешь внутри callback сделать операцию направленную на освобождение указателя - будет утечка. RAII не работает в этом сценарии. Танцы с оборачниваем утечки в std::list не особо имеют смысла.

Прочитал внимательнее твой пост. Не надо конвертировать итератор в указатель. Нет никаких гарантий, что структура итератора равна по размеру указателю (и скорее всего она не равна). То есть итератор в общем случае непредставим в виде void*. Разве что делать new и перемещать итератор в кучу, но это явный over-engineering, а потом ему делать delete.

У std::shared_ptr есть метод get, который возвращает сырой указатель, который можно кастовать в void*. Разумеется, чтобы никто не освободил память и указатель оставался валидным, shared_ptr должен где-то хранится до того момента, когда callback уже точно не будет вызван.

Либо всё ещё проще - умные указатели это сахар для C++ кода, при вызове C кода делаешь обычный new и передаёшь этот указатель. А при вызове твоего callback, делаешь delete. Это нормально, так как ты в любом случае делаешь ручное освобождение, не важно это удаление из std::list с автоматическим вызовом деструктора shared_ptr или ручной delete. Callback забудут вызвать или ты забудешь внутри callback сделать операцию направленную на освобождение указателя - будет утечка. RAII не работает в этом сценарии. Танцы с оборачниваем утечки в std::list не особо имеют смысла.

У std::shared_ptr есть метод get, который возвращает сырой указатель, который можно кастовать в void*. Разумеется, чтобы никто не освободил память и указатель оставался валидным, shared_ptr должен где-то хранится до того момента, когда callback уже точно не будет вызван.

Либо всё ещё проще - умные указатели это сахар для C++ кода, при вызове C кода делаешь обычный new и передаёшь этот указатель. А при вызове твоего callback, делаешь delete. Это нормально, так как ты в любом случае делаешь ручное освобождение, не важно это удаление из std::list с вызовом деструктора shared_ptr или ручной delete. Callback забудут вызвать или ты забудешь внутри callback сделать операцию направленную на освобождение указателя - будет утечка. RAII не работает в этом сценарии. Танцы с оборачниваем утечки в std::list не особо имеют смысла.

У std::shared_ptr есть метод get, который возвращает сырой указатель, который можно кастовать в void*. Разумеется, чтобы никто не освободил память и указатель оставался валидным, shared_ptr должен где-то хранится до того момента, когда callback уже точно не будет вызван.

Либо всё ещё проще - умные указатели это сахар для C++ кода, при вызове C кода делаешь обычный new и передаёшь этот указатель. А при вызове твоего callback, делаешь delete. Это нормально, так как ты в любом случае делаешь ручное освобождение, не важно это удаление из std::list с вызовом деструктора shared_ptr или ручной delete. Callback забудут вызвать или ты забудешь внутри callback сделать операцию направленную на освобождение указателя - будет утечка. Танцы с оборачниваем утечки в std::list не особо имеют смысла.

У std::shared_ptr есть метод get, который возвращает сырой указатель, который можно кастовать в void*. Разумеется, чтобы никто не освободил память и указатель оставался валидным, shared_ptr должен где-то хранится.

Либо всё ещё проще - умные указатели это сахар для C++ кода, при вызове C кода делаешь обычный new и передаёшь этот указатель. А при вызове твоего callback, делаешь delete. Это нормально, так как ты в любом случае делаешь ручное освобождение, не важно это удаление из std::list с вызовом деструктора shared_ptr или ручной delete. Callback забудут вызвать или ты забудешь внутри callback сделать операцию направленную на освобождение указателя - будет утечка. Танцы с оборачниваем утечки в std::list не особо имеют смысла.