Смысл отдельного экземпляра shared_ptr состоит в том, чтобы гарантировать (насколько это возможно), что пока этот shared_ptr находится в области видимости, объект, на который он указывает, будет существовать, потому что его счетчик ссылок будет не меньше 1.
Class::only_work_with_sp(boost::shared_ptr<foo> sp)
{
// sp points to an object that cannot be destroyed during this function
}
Таким образом, используя ссылку на shared_ptr, вы отключаете эту гарантию. Итак, во втором случае:
Class::only_work_with_sp(boost::shared_ptr<foo> &sp) //Again, no copy here
{
...
sp->do_something();
...
}
Откуда вы знаете, что sp->do_something() не взорвется из-за нулевого указателя?
Все зависит от того, что находится в этих разделах кода «...». Что, если вы вызовете что-то во время первого "...", которое имеет побочный эффект (где-то в другой части кода) очистки shared_ptr для того же объекта? А что, если он окажется единственным оставшимся shared_ptr отличным от этого объекта? До свидания, объект, именно там, где вы собираетесь его использовать.
Итак, есть два способа ответить на этот вопрос:
Очень внимательно изучите исходный код всей вашей программы, пока не убедитесь, что объект не умрет во время выполнения тела функции.
Измените параметр обратно на отдельный объект, а не на ссылку.
Общий совет, который здесь применим: не беспокойтесь о внесении рискованных изменений в свой код ради производительности, пока вы не рассчитали время для своего продукта в реалистичной ситуации в профилировщике и окончательно не измерили, что изменение, которое вы хотите внести, приведет к значительная разница в производительности.
Обновление для JQ комментатора
Вот надуманный пример. Это заведомо просто, поэтому ошибка будет очевидна. На реальных примерах ошибка не так очевидна, потому что она скрыта слоями реальных деталей.
У нас есть функция, которая куда-то отправит сообщение. Это может быть большое сообщение, поэтому вместо использования std::string, который, вероятно, копируется при передаче в несколько мест, мы используем shared_ptr в строке:
void send_message(std::shared_ptr<std::string> msg)
{
std::cout << (*msg.get()) << std::endl;
}
(Мы просто «отправляем» его на консоль для этого примера).
Теперь мы хотим добавить возможность запоминать предыдущее сообщение. Нам нужно следующее поведение: должна существовать переменная, содержащая самое последнее отправленное сообщение, но пока сообщение отправляется, не должно быть предыдущего сообщения (переменная должна быть сброшена перед отправкой). Итак, мы объявляем новую переменную:
std::shared_ptr<std::string> previous_message;
Затем мы изменяем нашу функцию в соответствии с указанными нами правилами:
void send_message(std::shared_ptr<std::string> msg)
{
previous_message = 0;
std::cout << *msg << std::endl;
previous_message = msg;
}
Итак, перед тем, как начать отправку, мы отбрасываем текущее предыдущее сообщение, а затем, после завершения отправки, мы можем сохранить новое предыдущее сообщение. Все хорошо. Вот тестовый код:
send_message(std::shared_ptr<std::string>(new std::string("Hi")));
send_message(previous_message);
И как и ожидалось, это напечатает Hi! дважды.
Теперь появляется мистер Сопровождающий, который смотрит на код и думает: Эй, этот параметр для send_message - это shared_ptr:
void send_message(std::shared_ptr<std::string> msg)
Очевидно, это можно изменить на:
void send_message(const std::shared_ptr<std::string> &msg)
Подумайте об увеличении производительности, которое это принесет! (Неважно, что мы собираемся отправить обычно большое сообщение по какому-либо каналу, поэтому повышение производительности будет настолько незначительным, что его невозможно будет измерить).
Но настоящая проблема в том, что теперь тестовый код будет демонстрировать неопределенное поведение (в отладочных сборках Visual C ++ 2010 он дает сбой).
Мистер Сопровождающий удивлен этим, но добавляет защитную проверку к send_message в попытке предотвратить возникновение проблемы:
void send_message(const std::shared_ptr<std::string> &msg)
{
if (msg == 0)
return;
Но, конечно, он все равно продолжается и вылетает, потому что msg никогда не имеет значения null, когда вызывается send_message.
Как я уже сказал, когда весь код так близко расположен в тривиальном примере, легко найти ошибку. Но в реальных программах с более сложными отношениями между изменяемыми объектами, которые содержат указатели друг на друга, легко сделать ошибку и сложно построить необходимые тестовые примеры для обнаружения ошибки.
Простое решение, когда вы хотите, чтобы функция могла полагаться на shared_ptr, продолжающее быть ненулевым на всем протяжении, состоит в том, чтобы функция выделяла свое собственное истинное shared_ptr, а не полагалась на ссылку на существующий shared_ptr.
Обратной стороной является то, что скопированный shared_ptr не является бесплатным: даже «безблокировочные» реализации должны использовать заблокированную операцию для соблюдения гарантий многопоточности. Таким образом, могут возникнуть ситуации, когда программу можно значительно ускорить, заменив shared_ptr на shared_ptr &. Но это изменение не может быть безопасно внесено во все программы. Это меняет логический смысл программы.
Обратите внимание, что аналогичная ошибка возникла бы, если бы мы использовали std::string вместо std::shared_ptr<std::string>, и вместо:
previous_message = 0;
чтобы очистить сообщение, мы сказали:
previous_message.clear();
Тогда симптомом будет случайная отправка пустого сообщения вместо неопределенного поведения. Стоимость дополнительной копии очень большой строки может быть намного более значительной, чем стоимость копирования shared_ptr, поэтому компромисс может быть другим.
person
Daniel Earwicker
schedule
30.11.2008
