повысить asio и распространение shared_ptrs

Question

Я недавно начал использовать повышение. До сих пор большинство вещей было довольно простым. Но одна вещь, которая сводит меня с ума, - это распространение shared_ptr на всем протяжении boost. Даже в простых примерах используется shared_ptr.

Итак, мой вопрос, использую ли я boost для приема tcp-соединений, а затем обрабатываю их. Пока я гарантирую, что объекты, созданные в куче (boost :: asio :: ip :: tcp :: socket и класс, который будет вызываться обратно для асинхронных методов), не будут удалены, пока я не закончу использовать tcp тогда мне не нужно shared_ptr исправить?

Я написал простой tcp сервер и клиент, не использующий общий ptr, он работает. Но я просто хотел бы получить внешнее подтверждение, что моя оценка верна.

Кроме того, по вашему опыту, вам когда-нибудь приходилось нуждаться в , чтобы использовать shared_ptr для успокоения наддува?

Answer 1

Прочитайте документацию для io_service деструктора

Описанная последовательность уничтожения выше позволяет программам упростить управление их ресурсами с помощью shared_ptr <>. Где объект время жизни связано с временем жизни соединение (или некоторая другая последовательность асинхронные операции), shared_ptr к объекту будет связан в обработчики для всех асинхронных операции, связанные с этим. это работает следующим образом:

Когда заканчивается одно соединение, все связанные асинхронные операции полный. Соответствующий обработчик объекты уничтожены, и все shared_ptr ссылки на объекты уничтожены.

Чтобы закрыть весь программа, функция io_service stop () вызывается для завершения любого run () вызывает как можно скорее. деструктор io_service, определенный выше уничтожает все обработчики, вызывая все shared_ptr ссылки на все объекты соединения, подлежащие уничтожению.

другими словами, будет экспоненциально проще использовать shared_ptr вместо голых указателей.

Answer 2

shared_ptr или что-то подобное (vector, auto_ptr и т. Д.) Требуется для обеспечения безопасности исключений. В тот момент, когда вы вводите в свой код вызов delete, может возникнуть исключение, которое приведет к пропуску удаления, утечка памяти.

Если вы используете все объекты, размещенные в стеке, и можете с этим справиться, сделайте это любым способом. Я предполагаю, что причина большинства shared_ptr, которые вы видите, в том, что кто-то хочет хранить объект с полиморфным поведением и не хочет подвергаться проблеме среза.

Answer 3

Подсчет ссылок присущи асинхронным операциям. В противном случае невозможно узнать, когда объект больше не используется. Вы можете избежать shared_ptr, сохранив свой счетчик ссылок. Но вы бы в значительной степени реализовали то же самое. Проблема здесь не в shared_ptr, а в вашем отношении к ней. Вы просто должны признать, что подсчет ссылок необходим для асинхронного кода, поэтому shared_ptr является естественным решением.