Я использовал обратные вызовы, чтобы уменьшить связь между некоторыми классами C ++. Чтобы определить термины: я буду называть класс, делающий обратные вызовы вызывающим, а класс, получающий обратный вызов, вызываемым. Обычно (но не обязательно) вызываемый абонент владеет абонентом. По замыслу звонящий не знает о вызываемом абоненте.
Я сталкиваюсь с проблемой, связанной с продолжительностью жизни объекта вызывающего: у него нет гарантии, что он останется живым после любого произвольного обратного вызова. Возьмите этот простой пример:
void caller::f()
{
/* Some work */
if (...)
{
/* [1] Execute callback */
_callee->callback(this);
}
/* [2] Some more work */
}
Скажите, что вызываемый абонент динамически назначил вызывающего и зарегистрировался для обратного вызова специально для ожидания возникновения определенного условия. Когда это произойдет, вызываемый будет удалять вызывающего изнутри обратного вызова в [1]. Если это так, управление вернется к caller :: f, но this
будет удалено, и любой код в [2] более чем вероятен сбой.
В общем случае, вызывающая сторона не может ничего сказать о вызываемой стороне. Он не знает, владеет ли вызываемый this
или может ли он освободить this
, поэтому мне потребуются некоторые общие средства предотвращения освобождения для области действия функции-члена вызывающего абонента.
Я полагаю, что возможное решение вращается вокруг boost::shared_ptrs
и enable_shared_from_this
, хотя я никогда не использовал его. Поскольку эти обратные вызовы выполняются очень часто (более 40 раз в секунду) на мобильных устройствах с ограниченной вычислительной мощностью, я также беспокоюсь о накладных расходах, связанных с созданием и передачей такого количества shared_ptrs
.
Делегирование - довольно распространенная модель в Objective-C. Я гораздо менее знаком с общими шаблонами проектирования C ++. Есть ли быстрое и простое решение этой проблемы? Если нет, то как этот дизайн обычно выполняется в C ++?