Должен ли я перейти от использования boost :: shared_ptr к std :: shared_ptr?

Question

Я хотел бы включить поддержку C ++ 0x в GCC с -std=c++0x.Мне не обязательно нужна какая-либо из поддерживаемых в настоящее время функций C ++ 11 в GCC 4.5 (и скоро 4.6), но я хотел бы начать к ним привыкать.Например, в некоторых местах, где я использую итераторы, будет полезен тип auto.

Но опять же, мне не нужны какие-либо из поддерживаемых в настоящее время функций.Цель здесь состоит в том, чтобы побудить меня включить функции нового стандарта в мой словарный запас программирования.

Исходя из того, что вы знаете о поддержке C ++ 11, полезно ли включить ее в GCC, а затем охватить ее, например, переключившись с использования boost::shared_ptr на std::shared_ptr исключительно какэти два не смешиваются?

PS: я знаю этот хороший вопрос , который сравнивает различные варианты shared_ptr, но я спрашиваю совет более высокого уровня, по которомуиспользовать до того, как стандарт будет доработан.Другой способ выразить это, когда компилятор, такой как GCC, говорит, что поддерживает «экспериментальную функцию», означает ли это, что я могу столкнуться со странными ошибками во время компиляции, которые будут основными поглотителями времени и источником загадочных вопросов в StackOverflow?

Редактировать : Я решил переключиться обратно с std::shared_ptr, потому что я просто не доверяю его поддержке в GCC 4.5, как , показанный примером в этом вопросе .

Answer 1

Есть несколько причин для перехода на std::shared_ptr:

• Вы удалили зависимость от Boost.
• отладчики. В зависимости от вашего компилятора и отладчика, отладчик может быть «умным» около std::shared_ptr и отображать объект, на который указывает указатель, напрямую, где это, скажем, не способствует реализации. По крайней мере, в Visual Studio std::shared_ptr выглядит как простой указатель в отладчике, в то время как boost::shared_ptr предоставляет кучу внутренних улучшений.
• Другие новые функции, определенные в вашем связанном вопросе.
• Вы получаете реализацию, в которой почти гарантированно включена семантика перемещения, что может сэкономить несколько модификаций повторного счета. (Теоретически - я не проверял это сам) По крайней мере, с 2014-07-22 boost::shared_ptr понимает семантику перемещения.
• std::shared_ptr правильно использует delete [] для типов массивов, в то время как boost::shared_ptr вызывает неопределенное поведение в таких случаях (вы должны использовать shared_array или пользовательское средство удаления) (На самом деле я исправлен. См. this - это специализация только для unique_ptr, а не shared_ptr.)

И одна из главных явных причин не делать этого:

• Вы бы ограничились реализациями компилятора C ++ 11 и стандартной библиотеки.

Наконец, вам не нужно выбирать. (И если вы нацелены на конкретную серию компиляторов (например, MSVC и GCC), вы можете легко расширить это, чтобы использовать std::tr1::shared_ptr, когда доступно. К сожалению, не существует стандартного способа обнаружения поддержки TR1)

#if __cplusplus > 199711L
#include <memory>
namespace MyProject
{
    using std::shared_ptr;
}
#else
#include <boost/shared_ptr.hpp>
namespace MyProject
{
    using boost::shared_ptr;
}
#endif

Answer 2

Полагаю, это зависит от того, насколько вы используете повышение.Лично я использую его очень редко (фактически, библиотеку случайных чисел, в одном проекте).Недавно я начал использовать -std=c++0x для других своих проектов, и я использую в них новые функции std :: library, например shared_ptr.Мне нравится, чтобы мои проекты имели минимум зависимостей, поэтому я предпочел бы зависеть от реализации стандартной библиотеки компилятора, чем от boost.

Но я не думаю, что существует универсальный подход для всехответ на этот вопрос.

Answer 3

Вы должны всегда использовать std::shared_ptr везде, где это возможно, если это возможно, вместо повышения.Это в основном потому, что все новые интерфейсы, которые используют shared_ptr, будут использовать стандартный общий ptr.

Answer 4

Вероятно, неплохо бы начать привыкать к использованию std :: shared_ptr, если это разрешено компилятором. Поскольку интерфейс такой же, как и у shared_ptr boost, вы всегда можете переключиться обратно, если вам нужно.

Answer 5

Помимо согласованности реализации, boost::shared_ptr в настоящее время сохраняет как минимум два преимущества ниши по сравнению с std::shared_ptr:

• Доступность boost::make_shared_noinit.Это особенно полезно в сочетании с массивами, позволяя избежать затрат на нулевую инициализацию и накладных расходов на отдельное распределение.(FWIW, это также предлагаемое добавление к стандарту.)
• Boost.Python специально использует поддержку boost::shared_ptr для пользовательских типов, удаляющих текст, но сделать то же самое для std::shared_ptr.

Answer 6

Другая причина для переключения на std::shared_ptr: он поддерживает std::unique_ptr, то есть имеет конструктор.

boost::shared_ptr нет.

Answer 7

Если вы просто строите на одной платформе, которая подходит (сделайте переключатель)
(Примечание: у вас есть модульные тесты для проверки обратной совместимости, не так ли?)

Если вы компилируете на нескольких платформах, это становится немного более неловким, так как вам нужно проверить, что функции g ++ 4.5 доступны на всех платформах, которые вы используете (т.е. сборка для MAC / Linux по умолчанию компилятор Mac g ++ все еще работает пара версий за стандартными компиляторами в Linux).

Answer 8

Я обнаружил, что std :: shared_ptr быстрее, чем boost :: shared_ptr.Я сделал тест, вы можете просмотреть код и увидеть результаты круговой диаграммы, сравнивая общие указатели boost, Qt и std.

https://www.osletek.com. ..