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

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

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

Из того, что вы знаете о поддержке С++ 11, полезно включить его в GCC, а затем охватить, например, переключением с boost::shared_ptr на std::shared_ptr только в качестве двух дон 't mix?

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

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

Ответ 1

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

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

И одна важная причина:

Вы ограничиваете себя компилятором С++ 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

Ответ 2

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

Но я не думаю, что на этот вопрос есть ответ на один размер.

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

Еще одна причина перехода на std::shared_ptr: он поддерживает std::unique_ptr, т.е. имеет конструктор.

boost::shared_ptr не работает.

Ответ 7

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

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