Estoy usando MS VC 2008 y para algunos proyectos compilador Intel C++ 11.0. ¿Vale la pena usar las características tr1 en producción? ¿Permanecerán en un nuevo estándar?¿Vale la pena usar std :: tr1 en producción?
Por ejemplo, ahora uso stdext::hash_map. TR1 define std::tr1::unordered_map. Pero en la implementación de MS unordered_map es solo suyo stdext::hash_map, con plantilla de otra manera.
Mi consejo sería utilizar un alias para el espacio de nombres que contiene los elementos TR1 que utiliza. De esta forma, podrá "pasar" de usar la versión TR1 a la versión estándar cuando su compilador lo admita.
namespace cpp0x = std::tr1;
cpp0x::unordered_map<std::string, int> mymap;
para un compilador de C++ 0x, se convierte en la primera línea:
namespace cpp0x = std;
y se puede dejar el resto solo.
Sí, todo lo que está en tr1 será quédese allí. Algunas cosas serán aceptadas en std ::, pero se mantendrán en en tr1 también. Por lo tanto, ninguno de su código se romperá una vez que el nuevo estándar sea finalizado.
Perdónenme: no, no lo harán. Como se describe here:
dos notas se han añadido a la propuesta para que quede claro a los usuarios que en la transición de la TR a las futuras normas, los componentes TR no permanecerán en el espacio de nombres std :: TR1 y la configuración las macros desaparecerán
Pero vale la pena señalar que los proveedores de compiladores dispuestos a soportar tr1 ahora, probablemente no le quitarán la tierra de encima, y le proporcionarán algún tipo de método de transición.
Para el tr1::unordered_map tenga en cuenta que hay muchas implementaciones diferentes de Hash Maps posibles y que la implementación elegida por el estándar es bastante clásica ... pero puede no ser la que mejor se desempeñe para su tarea particular.
Lamentablemente, el estándar no requería la implementación de múltiples estrategias (aunque supongo que habría requerido bastante trabajo).
unordered_map estará en el nuevo estándar, hash_map no lo será. Tenga en cuenta que el espacio de nombre tr1 tampoco es estándar.
No sabía que std :: tr1 no era estándar. No tengo el estándar tr1 final, pero el borrador que estoy viendo (enlace PDF) dice: "Como las extensiones descritas en este informe técnico no son parte de la biblioteca estándar de C++, no deberían declararse directamente dentro del espacio de nombres. estándar. A menos que se especifique lo contrario, todos los componentes descritos en este informe técnico se declaran en el espacio de nombres std :: tr1. ". http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf – Ben
@Ben TR1 no es normativo para C++. –
La gran mayoría del código de la biblioteca que se agregará en C++ 0x ha existido desde hace bastante tiempo en el Boost C++ Libraries. Recomiendo encarecidamente utilizar Boost (es decir, boost::unordered_map), ya que funciona en un gran número de compiladores de ISO C++ 1998 y continuará funcionando (probablemente utilizando la implementación incorporada del compilador) en los compiladores de C++ 0x. Además, no necesitará cambiar el espacio de nombres, mientras que los elementos en std :: tr1 que están aprobados se moverán a std, ya que siempre estará disponible en boost ::, y no tendrá que preocuparse. sobre qué elementos de tr1 lo han convertido en el estándar. En resumen, Boost es el camino a seguir.
No estoy totalmente de acuerdo con eso. Usted tiene la ventaja de la portabilidad si usa la implementación de impulso, pero pierde en optimizaciones específicas de la plataforma y cosas como el soporte IDE (por ejemplo, la excelente compatibilidad con shared_ptr <> en el depurador de Visual Studio). –
@the_mandrill, estoy bastante seguro de que Boost utilizará la implementación estándar subyacente si está disponible ... ¿tiene algún punto de referencia que indique que la versión de refuerzo es más lenta donde está disponible la versión estándar? Si es así, ¿en qué plataforma y con qué versión de Boost? –
No conozco ningún punto de referencia, pero recuerdo comparando la versión de refuerzo de shared_ptr con la de VS.Net y el impulso parecía mucho más pesado, ya que extrae muchos más archivos y tiene ciertas peculiaridades en un número de compiladores Mientras tanto, VS.Net es libre de ser optimizado para el compilador local. Nunca he visto las implementaciones de impulso utilizar las versiones locales. –
No tengo claro qué quiere decir con la implementación elegida por el Estándar. El estándar prescribe el comportamiento O(), no las implementaciones.¿Hay un conjunto diferente de comportamiento O() que desee en contenedores asociativos? –
'O()' no siempre es significativo. Por ejemplo, en términos de reafilado. Todos los hashmaps tienen una inserción constante amortiguada, pero si no tiene un rehashing dinámico, algunas inserciones serán muy lentas (como cuando activa un realloc en un 'std :: vector :: push_back'). 'O (1)' da un margen de acción aquí y si necesita realizar inserciones frecuentes en un proceso de tiempo crítico, no es suficiente. –