¿Las características experimentales del C++ moderno son confiables para proyectos a largo plazo?

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. Veo, sin embargo, que está disponible en mi compilador actual como std::experimental::filesystem. ¿Es una buena idea usar funciones 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 funciones experimentales?

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

Quizá haya más cosas por las que preguntarse. ¿Por qué debo o no debo usarlos? Estoy desconcertado con un nuevo proyecto y no sé qué decidir.

1. ¿Está garantizado que todos los compiladores compatibles tengan las mismas funciones 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 función o, en el proceso de estandarización, podría surgir un defecto que obligaría a cambiar una función.

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

Alguien de la audiencia hizo una pregunta durante la charla “Panel de biblioteca estándar de C++” en CppCon 2016 (Youtube) sobre el potencial del nombre experimental para asustar a los usuarios de usar cualquier cosa dentro del espacio de nombres:

¿Ustedes consideran [the contents of the std::experimental namespace] producción lista y es ese un argumento que se puede hacer, [that] está efectivamente listo para la producción durante los próximos 3 años, y tal vez tenga que cambiar su código 3 años después, ¿tal vez?

Michael Wong (presidente de SG5 y SG14 y editor de Concurrency TS) respondió primero a 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 % cae desde el aire. Queremos asegurarnos de que no sea un impedimento para que lo uses. Puede entender por qué queremos poner grandes funciones, grandes grupos de funciones, en ese contexto, para que no perturbe el resto del sistema de la biblioteca, pero también le facilita su uso. Ahora puede activar GCC con un indicador específico para Concepts, ya sabe, eso realmente le facilita segmentarlo.

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

Voy a tomar la posición contraria aquí. Una de las cosas de la hierba [Sutter] dijo como convocante del WG21, el grupo estándar, cuando emprendimos el camino de los TS, no pensó que los TS habrían tenido éxito hasta que no hayamos logrado avanzar en algo, porque significa que no estamos siendo lo suficientemente experimentales , no estamos siendo lo suficientemente ambiciosos en lo que estamos usando para los TS. Realmente queremos eso experimental para ser una pista de que, sí, estas cosas están sujetas a cambios, no estamos obligados a eso, y podemos equivocarnos. Esto es para bajar nuestra barrera por las cosas que consideramos tan ambiciosas y alcanzar como podamos. […] Ahora que el estándar parece estar en un ciclo de lanzamiento de tres años, deberíamos ser mucho más ambiciosos al incluir funciones realmente experimentales en el TS, y tal vez avanzar más rápidamente en el estándar principal. Pero nuevamente, este será un tema divertido para discutir en los próximos [C++ standard committee] reuniones

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

Es importante hacer una distinción entre la experimentación de la interfaz y la experimentación de la implementación, porque cuando dices “listo para producción”, ¿qué significa? Por lo general, “listo para la producción”, pensaría en eso hablando de la implementación. Es muy posible que una implementación [of something in std::experimental] ser absolutamente […] a prueba de balas. […] Algo como […] la <random> cabecera en TR1, [it was] muy, muy agradable en TR1, y podría haber tenido una implementación absolutamente a prueba de balas de eso, pero resultó que la interfaz se agitó sustancialmente [before the release of] C++11 y […] si supiéramos entonces lo que hacemos ahora, poniendo en un experimental Hubiera sido una mejor señal para la gente que, “Oye, tal vez no quieras usar std::experimental::variate_generator porque, ja, ja, va a desaparecer en C++ 11″.

Así que parece que hay cierto deseo entre los desarrolladores de bibliotecas estándar y los miembros del comité de que, al menos en el futuro, el contenido de la std::experimental espacio de nombres debe ser verdaderamente “experimental” en la naturaleza, y no debe darse por sentado que algo en std::experimental lo convertirá en el estándar C++.

Y no, según tengo entendido, depende de los proveedores de bibliotecas estándar si proporcionan implementaciones para las diversas funciones dentro de std::experimental.

“Experimental” es un término ligeramente exagerado. los filesystem La biblioteca se originó en Boost y pasó por algunas iteraciones allí, antes de enviarse a ISO.

Sin embargo, las normas ISO son intencionalmente muy conservador. Llamarlo experimental significa que ISO explícitamente no promete que el nombre 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 esa es exactamente la razón por la cual un estándar futuro podría romper su código existente. Idealmente, rompería su código si y solo si dependiera de ese caso de esquina, pero eso no es una garantía.

Quizá haya más cosas por las que preguntarse.

Algunos puntos a considerar:

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

• ¿Qué tan grande es su base de código? ¿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?

• ¿Cuáles son las alternativas?

  • Use la característica experimental, luego adapte el código a las modificaciones cuando/si se estandariza. Podría ser tan fácil como eliminar experimental::o tan difícil como forzar soluciones temporales.
  • Agregue una capa de abstracción (comentario de Serge Ballesta). Si la función experimental cambia, sus reescrituras se aíslan. Para una característica estándar, podría ser excesivo (std::filesystem ya es una capa de abstracción…).
  • Utilice otra API/biblioteca. Mismas preguntas: ¿madurez? robustez? ¿estabilidad? ¿portabilidad? ¿facilidad de uso? ¿caracteristicas?
• En el caso de std::filesystem (o el TS de red), existe boost::filesystem (resp. boost::asio) como alternativa o respaldo, en caso de que el experimental uno falla o desaparece.