¿Cuáles son las mejores prácticas para el uso autoconf
en conjunción con shared_ptr
y otros/BOOST TR1 plantillas de C++ 0x fin de maximizar la portabilidad y facilidad de mantenimiento?Cómo utilizar autoconf con C++ 0x cuenta
Con autoconf
puedo determinar si es shared_ptr
disponible como std::tr1::shared_ptr
y/o boost::shared_ptr
. Dada que la misma característica tiene dos nombres diferentes, tengo las siguientes preguntas:
- en el código, cómo debe ser referenciado
shared_ptr
? - ¿Debería preferir
std::tr1::shared_ptr
a más deboost::shared_ptr
?
Para el primero, el código está utilizando condicionales del preprocesador permitiendo referencias no calificadas para shared_ptr
, a la
#if HAVE_STD_TR1_SHARED_PTR
using std::tr1::shared_ptr;
#elif HAVE_BOOST_SHARED_PTR
using boost::shared_ptr;
#else
#error "No definition for shared_ptr found"
#endif
En segundo lugar, el código utiliza std::tr1::
sobre boost::
para minimizar dependencias de bibliotecas externas (incluso si las bibliotecas son ampliamente utilizado).
¿Son estas dos soluciones comunes? ¿Hay mejores?
No veo qué tipo de plantilla añade tu plantilla más que la sugerencia original del póster. Está "contaminado" con shared_ptr. Has contaminado cosas con SharedPtr :: Tipo. Ambos parecen equivalentes, y el suyo implica menos tipeo. ¿Qué cumple tu plantilla typedef más allá de la declaración using en la publicación original? –
Lo tocas: ya no necesitas desplegar estos nombres en el espacio de nombres global. Mi método no necesariamente agrega nombres globales; puedes espacio de nombres si quieres. Y si no lo haces, es mucho menos probable que el mío entre en conflicto con los nombres en otra biblioteca. –
Dado que shared_ptr eventualmente estará en std :: y que autoconf puede determinar en qué espacio de nombres se define shared_ptr, me inclino por "namespace std {using :: shared_ptr;}" si no se define std :: shared_ptr. –
themis