c++ - ¿Debo cambiar de usar boost:: shared_ptr a std:: shared_ptr?

stl c++11

Question

Me gustaría habilitar el soporte para C ++ 0x en GCC con -std=c++0x . No necesariamente necesito absolutamente ninguna de las características de C ++ 11 actualmente compatibles en GCC 4.5 (y pronto 4.6), pero me gustaría empezar a acostumbrarme a ellas. Por ejemplo, en algunos lugares donde utilizo iteradores, un tipo auto sería útil.

Pero, de nuevo, no necesito ninguna de las funciones compatibles actualmente. El objetivo aquí es alentarme a incorporar las características del nuevo estándar en mi "vocabulario" de programación.

Por lo que sabe del soporte de C ++ 11, es una buena idea habilitarlo en GCC, y luego abrazarlo, por ejemplo, cambiando de usar boost::shared_ptr a std::shared_ptr exclusivamente como los dos don '' t mezclar?

PD: Soy consciente de esta buena pregunta que compara los diferentes sabores de shared_ptr pero estoy pidiendo un consejo de nivel superior sobre el cual usar antes de que se finalice el estándar. Otra forma de decirlo es que cuando un compilador como GCC dice que admite una "característica experimental", ¿significa eso que es probable que encuentre errores extraños durante la compilación que serán los principales sumideros de tiempo y una fuente de preguntas crípticas en StackOverflow?

Editar : decidí cambiar desde std::shared_ptr porque simplemente no confío en su soporte en GCC 4.5 como se muestra por ejemplo en esta pregunta .

Answer 1

Además de la coherencia de la implementación, boost::shared_ptr actualmente conserva al menos dos ventajas de nicho sobre std::shared_ptr :

• La disponibilidad de boost::make_shared_noinit . Es particularmente útil junto con las matrices, evitando tanto el costo de inicialización cero como la sobrecarga de la asignación por separado. (FWIW, también es una adición propuesta al estándar).
• Boost.Python hace un uso especial del boost::shared_ptr de boost::shared_ptr para eliminadores personalizados borrados por tipo, pero aún no hace lo mismo para std::shared_ptr .

Answer 2

Encontré que std :: shared_ptr es más rápido que boost :: shared_ptr. Hice una prueba, puede revisar el código y ver los resultados del gráfico circular que comparan impulso, Qt y punteros compartidos estándar.

Answer 3

Hay un par de razones para cambiar a std::shared_ptr :

• Eliminas una dependencia en Boost.
• Depuradores Dependiendo de su compilador y depurador, el depurador puede ser "inteligente" sobre std::shared_ptr y mostrar el objeto apuntado directamente, donde no sería para decir, la implementación de boost. Al menos en Visual Studio, std::shared_ptr parece un puntero simple en el depurador, mientras boost::shared_ptr expone un montón de innards de impulso.
• Otras nuevas características definidas en su pregunta vinculada.
• Obtiene una implementación que está casi garantizada como semántica de movimiento habilitada, lo que podría ahorrar algunas modificaciones de refcount. (En teoría, no lo he probado yo mismo) Desde 2014-07-22 al menos, boost::shared_ptr entiende la semántica de movimientos.
• std::shared_ptr utiliza correctamente delete [] en tipos de matriz, mientras boost::shared_ptr causa un comportamiento indefinido en tales casos (debe usar shared_array o un deleter personalizado) (En realidad, estoy corregido. Vea this - la especialización para esto es para unique_ptr only, no shared_ptr .)

Y una de las principales razones evidentes para no:

• Te limitarías al compilador de C ++ 11 y a las implementaciones de la biblioteca estándar.

Finalmente, realmente no tienes que elegir. (Y si se dirige a una serie de compiladores específica (por ejemplo, MSVC y GCC), puede extender fácilmente esto para usar std::tr1::shared_ptr cuando esté disponible. Desafortunadamente, no parece haber una forma estándar de detectar la compatibilidad con 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 4

Otra razón para cambiar a std::shared_ptr : admite std::unique_ptr , es decir, tiene constructor.

boost::shared_ptr no lo hace.

Answer 5

Probablemente no sea una mala idea comenzar a acostumbrarse a usar std :: shared_ptr cuando lo permita el compilador. Como la interfaz es la misma que la shared_ptr de boost, siempre puedes volver atrás si es necesario.

Answer 6

Si solo estás construyendo sobre la única plataforma que está bien (haz el cambio)
(Nota: usted tiene pruebas unitarias para validar la compatibilidad con versiones anteriores, ¿no?)

Si compila en múltiples plataformas es donde se torna un poco más incómodo ya que necesita validar que las características en g ++ 4.5 están disponibles en todas las plataformas que usa (es decir, construir para MAC / Linux el compilador Mac g ++ predeterminado todavía es un par de la versión está detrás de los compiladores por defecto en Linux).

Answer 7

Siempre debe usar std::shared_ptr siempre que sea posible, si está disponible, en lugar de aumentar. Esto es básicamente porque todas las nuevas interfaces que usan shared_ptr usarán el ptr compartido estándar.

Answer 8

Supongo que depende de cuánto usas boost. Personalmente, solo lo uso con moderación (de hecho, la biblioteca de números aleatorios, en un solo proyecto). Recientemente comencé a usar -std=c++0x para mis otros proyectos, y utilizo las nuevas características de std :: library como shared_ptr en ellos. Me gusta que mis proyectos tengan el mínimo de dependencias, por lo que prefiero depender de la implementación de la biblioteca estándar del compilador que de la mejora.

Pero no creo que haya una respuesta única para esta pregunta.