Следует ли мне переключиться с использования повышения :: shared_ptr на std :: shared_ptr?
Я хотел бы включить поддержку 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, как , как показано в примере в этом вопросе .
]
3 ответа
Есть несколько причин для перехода на std::shared_ptr :
- Вы удалили зависимость от Boost.
- отладчики. В зависимости от вашего компилятора и отладчика, отладчик может быть «умным» в отношении
std::shared_ptrи напрямую показывать объект, на который указывает указатель, что, например, не способствует его реализации. По крайней мере, в Visual Studiostd::shared_ptrвыглядит как простой указатель в отладчике, в то время какboost::shared_ptrпредоставляет множество внутренних функций boost. - Другие новые функции определены в вашем связанном вопросе.
-
Вы получаете реализацию, в которой почти гарантированно включена семантика перемещения, что может сохранить несколько модификаций refcount. (Теоретически - я не проверял это сам) По крайней мере, с 2014-07-22boost::shared_ptrпонимает семантику перемещения. -
std::shared_ptrправильно используетdelete []для типов массивов, в то время какboost::shared_ptrвызывает неопределенное поведение в таких случаях (вы должны использоватьshared_arrayили пользовательское средство удаления) (На самом деле я исправлен. См. этот - специализация для этого только для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
Вы должны всегда использовать std::shared_ptr везде, где это возможно, если это возможно, вместо повышения. Это в основном потому, что все новые интерфейсы, которые используют shared_ptr, будут использовать стандартный общий ptr.
Помимо согласованности реализации, boost::shared_ptr в настоящее время сохраняет по крайней мере два преимущества ниши по сравнению с std::shared_ptr:
- Наличие
boost::make_shared_noinit. Это особенно полезно в сочетании с массивами, позволяя избежать затрат на нулевую инициализацию и накладных расходов на отдельное распределение. (FWIW, это также предложенное дополнение к стандарту.) - Boost.Python специально использует поддержку
boost::shared_ptrдля стертых по типу пользовательских программ удаления, но не делает. пока не сделайте то же самое дляstd::shared_ptr.