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


87

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 funciones experimentales, asumiendo que en el futuro podría agregar algo como:

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

Mis preocupaciones son:

1. ¿Está garantizado que todos los compiladores compatibles tengan las mismas características experimentales?

2. ¿Son las funciones experimentales propensas a grandes cambios que las hacen poco fiables?

Quizás haya más cosas sobre las que preguntarse. ¿Por qué debería o no debería utilizarlos? Estoy desconcertado con un nuevo proyecto y no sé qué decidir.


25
¿No responde la palabra experimental a sus preguntas?
101010

6
Principalmente una cuestión de gustos, pero evitaría saturar el código #idef CXX17. En mi humilde opinión, la forma portátil es poner todo el código relacionado con el sistema de archivos en una sola unidad de compilación (puede ser una clase), usarlo en las partes restantes del código, codificarlo con el estándar actual C ++ 11/14. Documente cómo y por qué lo escribe así y eventualmente lo transfiera a C ++ 17 más tarde durante una fase de mantenimiento, si tiene sentido. (comentando la pregunta original)
Serge Ballesta

4
Fue sólo "experimental" como candidato para ingresar al estándar. No es un reflejo de la calidad del código.
Galik

5
Hubo bastantes cambios entre la versión "experimental" y la versión final de C ++ 17, consulte el documento P0492R1
Bo Persson

7
En el caso de filesystemque incurra en un riesgo mucho menor al usarlo que otras cosas, ya que ya sabe que se estandariza en C ++ 17, y la especificación exacta de C ++ 17 está disponible públicamente. Entonces, todo lo que tiene que hacer es asegurarse de usar solo las experimental::filesystemcaracterísticas que están en la especificación C ++ 17. Y, por supuesto, debe saber que todas sus plataformas específicas son compatibles con uno de experimental::filesystemC ++ 17 std::filesystem.
Howard Hinnant

Respuestas:


79
  1. ¿Está garantizado que todos los compiladores compatibles tengan las mismas características experimentales?

No, las funciones experimentales son opcionales.

  1. ¿Son las funciones experimentales propensas a grandes cambios que las hacen poco fiables?

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 cambiar una característica.

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


2
En referencia al segundo punto, tenga en cuenta que estoy hablando de funciones que ya se aceptan, pero que pueden ser diferentes.
The Quantum Physicist

14
@TheQuantumPhysicist: "ya aceptado" es un concepto complicado. Cualquier cosa se puede eliminar en cualquier momento mediante la aceptación posterior de un cambio para eliminarlo, y esto ha sucedido con todos los estándares. Probablemente desee esperar hasta al menos el Borrador de la Norma Internacional antes de que el conjunto de funciones sea razonablemente confiable.
Kerrek SB

1
@KerrekSB: ¿No te refieres al Borrador Final del Estándar Internacional, también conocido como FDIS? ? La redacción es un proceso bastante permanente.
MSalters

1
@MSalters: No, el DIS probablemente sea lo suficientemente bueno si tienes prisa. Y es posible que esta vez no tengamos un FDIS de todos modos.
Kerrek SB

4
@KerrekSB: Yo era prácticamente el organismo nacional de los Países Bajos en torno a C ++ 03;). Teníamos un secretario nacional para el SC22 que conocía los procedimientos ISO y cómo responder a un FDIS, pero no qué. Aparte de nuestro delegado de WG14, Randy Marques, ninguno de nuestros delegados de SC22 sabía nada sobre C ++. Y Randy se estaba burlando del hecho de que C ++ necesitaría más páginas para definir todo su UB que las que C necesitaba para el comportamiento definido; no querría que él respondiera a ese FDIS;)
MSalters

50

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

¿Ustedes consideran que [el contenido del std::experimentalespacio de nombres] está listo para la producción y es un argumento que se puede hacer, [que] está efectivamente listo para la producción para los próximos 3 años, y tal vez tengan 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ó la pregunta primero:

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 lanza al aire. Queremos asegurarnos de que no sea un impedimento para que lo use. Puede comprender por qué queremos poner grandes funciones, grandes grupos de funciones, en ese contexto, para que no moleste al resto de todo el sistema de la biblioteca, pero también le facilite su uso. Ahora puede activar GCC con una bandera específica para Conceptos, ya sabe, que en realidad le facilita la segmentación.

Alisdair Meredith (ex presidente del LWG) luego hizo un seguimiento:

Voy a tomar la posición contraria aquí. Una de las cosas que Herb [Sutter] dijo como coordinador del WG21, el grupo estándar, cuando emprendimos el camino de los TSes es que no pensó que los TSes hubieran tenido éxito hasta que no hubiéramos podido presentar algo, porque significa que no estamos siendo lo suficientemente experimentales, no estamos siendo lo suficientemente ambiciosos en lo que estamos usando los TSes. Realmente queremos esoexperimentalpara dar una pista de que, sí, estas cosas están sujetas a cambios, no estamos vinculados a eso y podemos hacer las cosas mal. Esto es para reducir nuestra barrera para las cosas que consideramos que son tan ambiciosas y de alcance como podamos [...] 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 quizás avanzando más rápidamente hacia el estándar principal en sí. Pero, nuevamente, este será un tema divertido para discutir 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 la experimentalidad de la interfaz y la experimentalidad de la implementación, porque cuando dice "producción lista", ¿qué significa eso? Por lo general, "listo para la producción", pensaría en eso hablando de la implementación. Es muy posible que una implementación [de algo en std::experimental] sea absolutamente [...] a prueba de balas. [...] Algo como [...] el <random>encabezado en TR1, [fue] realmente, muy bueno 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 [antes del lanzamiento de] C ++ 11 y [...] si supiéramos entonces lo que hacemos ahora, poniendo un porque, ja, ja, va a desaparecer en C ++ 11 ".experimental hubiera sido una mejor señal para la gente de que "Oye, tal vez no quieras utilizarstd::experimental::variate_generator

Así que parece que hay algún deseo entre los desarrolladores de bibliotecas estándar y los miembros del comité que, en el futuro, al menos, el contenido del std::experimentalespacio de nombres deben ser verdaderamente "experimental" en la naturaleza, y no debe darse por sentado que algo en std::experimentalla voluntad conviértalo en el estándar C ++.

Y no, por lo que tengo entendido, depende de los proveedores de bibliotecas estándar si proporcionan implementaciones para las diversas funciones que contiene std::experimental.


47
10 años después de leer el nombre por primera vez, el hecho de que el encargado de mantenimiento de STL de Microsoft se llame STL todavía me hace reír.
Jörg W Mittag

19
@ JörgWMittag debería conocer a su responsable del compilador, Michael Sam Victor Collins
MM

28

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

Sin embargo, las normas ISO son intencionadamente muy conservadoras. 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 que 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.


8

Quizás haya más cosas sobre 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 tomar una decisión. ¡O pregúntales!

  • ¿Qué tamaño tiene 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?

  • Cuales son las alternativas?

    • Utilice la función experimental, luego adapte el código a las modificaciones cuando / si se estandariza. Podría ser tan fácil como eliminarlo experimental::o tan difícil como forzar soluciones alternativas.
    • 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. 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 respaldo, en caso de que experimentaluno falle o desaparezca.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.