pagina - ¿Son fiables las características experimentales de C++ moderno para proyectos a largo plazo?

curso de c++ completo

Question

Tengo un proyecto que actualmente usa C ++ 11/14, pero requiere algo como std::filesystem , que solo está disponible en C ++ 17, y por lo tanto no tengo la oportunidad de usarlo actualmente. Sin embargo, veo que está disponible en mi compilador actual como std::experimental::filesystem . ¿Es una buena idea usar características experimentales, suponiendo que en el futuro pueda agregar algo como:

#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif

Mis preocupaciones son:

1. ¿Se garantiza que todos los compiladores compatibles tengan las mismas características experimentales?

2. ¿Las características experimentales son propensas a grandes cambios que las hacen poco confiables?

Tal vez hay más cosas de las que preguntarse. ¿Por qué debería o no debería usarlos? Estoy desconcertado con un nuevo proyecto y no sé qué decidir.

Answer 1

1. ¿Se garantiza que todos los compiladores compatibles tienen las mismas características experimentales?

No, las características experimentales son opcionales.

2. ¿Las características experimentales son propensas a grandes cambios que las hacen poco confiables?

Sí, el comité de C ++ podría incluso decidir abandonar una característica o, en el proceso de estandarización, podría surgir un defecto que obligaría a una característica a cambiar.

En general, no es una buena idea depender de características experimentales. Las características experimentales son exactamente lo que dice la palabra (es decir, experimentar con).

Answer 2

Tal vez hay más cosas de las que preguntarse.

Algunos puntos a considerar:

• ¿Qué tan multiplataforma es tu proyecto? Si solo hay un compilador involucrado, entonces puede inspeccionar su implementación y realizar un seguimiento para decidir. O pregúntales!

• ¿Qué tan grande es tu código base? ¿Qué tan grande sería el impacto de los cambios?

• ¿Qué tan fundamentales para su proyecto son las características proporcionadas por la API / biblioteca / característica?

• Cuales son las alternativas?

  • Use la función experimental, luego adapte el código a las modificaciones cuando / si se estandariza. Puede ser tan fácil como eliminar experimental:: o tan difícil como forzar soluciones alternativas.
  • Agregue una capa de abstracción (comentario de Serge Ballesta). Si la característica experimental cambia, sus reescrituras están aisladas. Para una característica estándar, puede ser excesivo (std :: filesystem ya es una capa de abstracción ...).
  • Use otra API / biblioteca. Las mismas preguntas: madurez? robustez? ¿estabilidad? ¿portabilidad? ¿facilidad de uso? ¿caracteristicas?
• En el caso de std :: filesystem (o el TS de red), hay boost :: filesystem (resp. Boost :: asio) como alternativa o alternativa, en caso de que el experimental falle o desaparezca.

Answer 3

"Experimental" es un término ligeramente exagerado. La biblioteca del filesystem originó en Boost y pasó por algunas iteraciones allí, antes de ser enviada a ISO.

Sin embargo, las normas ISO son intencionalmente muy conservadoras. Llamarlo experimental significa que ISO explícitamente no promete que la denominación será estable; Está muy claro que necesitará volver a direccionar su código en algún momento en el futuro. Pero conociendo ISO, es probable que haya orientación sobre cómo hacerlo.

En cuanto a la compatibilidad entre compiladores, espere que sea razonable. Pero habrá casos de esquina (piense en las rutas relativas a la unidad de Windows, por ejemplo), y eso es exactamente por qué un estándar futuro podría romper su código existente. Idealmente, rompería su código si y solo dependiera de ese caso de esquina, pero eso no es una garantía.

Answer 4

Alguien de la audiencia hizo una pregunta durante la charla "C ++ Standard Library Panel" en CppCon 2016 ( YouTube ) sobre el potencial del nombre experimental para ahuyentar a los usuarios de usar cualquier cosa dentro del espacio de nombres:

¿Ustedes consideran que [el contenido del std::experimental namespace] está listo para la producción y es un argumento que se puede hacer, [que] está efectivamente listo para la producción durante los próximos 3 años, y tal vez tengan que cambiar su código 3 años ¿Tal vez más tarde?

Michael Wong (presidente de SG5 y SG14 y editor del Concurrency TS) respondió primero la pregunta:

Creo que hay un fuerte consenso dentro del comité de que está prácticamente listo para la producción. Como dije antes, en la mayoría de los casos, el 99% se deja caer en el aire. Queremos asegurarnos de que no sea un impedimento para que lo uses. Puede comprender por qué queremos poner grandes características, grandes grupos de características, en ese contexto, de modo que no perturbe el resto del sistema de la biblioteca, sino que también le facilite su uso. Ahora puede activar GCC con un indicador específico para Conceptos, ya sabe, que en realidad le facilita la segmentación.

Alisdair Meredith (ex presidente del LWG) luego siguió:

Voy a tomar la posición contraria aquí. Una de las cosas que Herb [Sutter] dijo como convocante del WG21, el grupo estándar, cuando iniciamos el camino de las TS es que no creía que las TS hubieran tenido éxito hasta que no hayamos presentado algo, porque significa que no estamos siendo lo suficientemente experimentales, no estamos siendo lo suficientemente ambiciosos en lo que estamos utilizando los TS. Realmente queremos que ese experimental sea ​​un indicio de que, sí, estas cosas están sujetas a cambios, no estamos vinculados a eso y podemos equivocarnos. Esto es para reducir nuestra barrera para las cosas que consideramos tan ambiciosas y alcanzables como podemos ahora. [...] Ahora el estándar parece estar en un ciclo de lanzamiento de tres años, deberíamos ser mucho más ambiciosos al poner características realmente experimentales en el TS, y tal vez avanzar las cosas más rápidamente en el estándar principal en sí. Pero, de nuevo, este será un tema divertido para que lo discutamos en las próximas reuniones [del comité estándar de C ++].

Stephan T. Lavavej (responsable de la implementación de STL de Microsoft) fue el último en responder:

Es importante hacer una distinción entre lo experimental de la interfaz y lo experimental de la implementación, porque cuando dices "producción lista", ¿qué significa eso? Por lo general, "listo para la producción", pensarías en eso hablando de la implementación. Es bastante posible que una implementación [de algo en std::experimental ] sea absolutamente a prueba de balas. [...] Algo así como [...] el encabezado <random> en TR1, [fue] realmente agradable en TR1, y podrías haber tenido una implementación absolutamente a prueba de balas de eso, pero resultó que la interfaz se agitó sustancialmente [antes del lanzamiento de] C ++ 11 y [...] si supiéramos lo que hacemos ahora, poner un experimental habría sido una mejor señal para la gente de que "Hey, tal vez no No quiero usar std::experimental::variate_generator porque, ja, ja, va a desaparecer en C ++ 11 ".

Por lo tanto, parece que existe un deseo entre los desarrolladores de bibliotecas estándar y los miembros del comité de que, al menos en el futuro, el contenido del std::experimental nombres std::experimental debería ser verdaderamente de naturaleza "experimental", y no debería darse por sentado. que algo en std::experimental lo convertirá en el estándar C ++.

Y no, hasta donde yo entiendo, depende de los vendedores de bibliotecas estándar si proporcionan implementaciones para las diversas características dentro de std::experimental .