c++ - ¿Hay un ''catch'' con FastFormat?
(6)
Acabo de leer sobre la biblioteca de formato FastFormat C ++ i / o , y parece demasiado bueno para ser cierto: más rápido incluso que printf, tipo seguro y con lo que considero una interfaz agradable:
// prints: "This formats the remaining arguments based on their order - in this case we put 1 before zero, followed by 1 again"
fastformat::fmt(std::cout, "This formats the remaining arguments based on their order - in this case we put {1} before {0}, followed by {1} again", "zero", 1);
// prints: "This writes each argument in the order, so first zero followed by 1"
fastformat::write(std::cout, "This writes each argument in the order, so first ", "zero", " followed by ", 1);
Esto parece casi demasiado bueno para ser verdad. Hay una trampa? ¿Has tenido experiencias buenas, malas o indiferentes con eso?
Encontré una "captura", aunque para la mayoría de las personas nunca se manifestará. Desde la página del proyecto:
Operación atómica No escribe los elementos de declaración uno a la vez, como IOStreams, por lo que no tiene problemas de atomicidad
La única forma en que puedo ver que esto sucede es si almacena ostream toda la salida de la llamada write() y luego la escribe en un solo paso. Esto significa que necesita asignar memoria, y si un objeto pasado a la llamada write() produce una gran cantidad de salida (varios megabytes o más), puede consumir hasta el doble de esa cantidad de memoria en los búferes internos (suponiendo que utiliza el crecimiento truco a-buffer-by-doubling-its-size-each-time).
Si solo lo está usando para iniciar sesión, y no, por ejemplo, descargando grandes cantidades de XML, nunca verá este problema.
La única otra "captura" que estoy viendo es:
Altamente portátil. Funcionará con todos los buenos compiladores modernos de C ++; ¡incluso funciona con Visual C ++ 6!
Por lo tanto, no funcionará con un compilador de C ++ antiguo, como cfront , mientras que iostreams es compatible con versiones cfront finales de los 80. Una vez más, me sorprendería si alguien alguna vez tuviera un problema con esto.
Si observa detalladamente en su página de referencia de rendimiento, notará que las buenas funciones antiguas de C printf -family siguen ganando en Linux. De hecho, el único caso de prueba en el que tienen un rendimiento deficiente es el caso de prueba que debería ser la concatenación de cadenas estáticas, donde esperaría que printf fuera un desperdicio. Además, GCC proporciona verificación de tipo estática en las llamadas a funciones de estilo de impresión, por lo que se reduce el beneficio de la seguridad de tipo. Entonces: si está ejecutando Linux y necesita el mejor rendimiento absoluto, FastFormat probablemente no sea la solución óptima.
¡Se ve bastante interesante! Buen consejo independientemente, y +1 para eso!
He estado jugando con eso por un tiempo. El principal inconveniente que veo es que FastFormat admite menos opciones de formato para la salida. Esto es, creo, una consecuencia directa de la forma en que se logra la mayor seguridad de tipo, y una buena compensación dependiendo de sus circunstancias.
La biblioteca depende de un par de variables de entorno, como se menciona en los documentos .
Eso podría no ser tan grave para algunas personas, pero preferiría que mi código fuera lo más autónomo posible. Si lo compruebo desde el control de origen, debería funcionar y compilarse. No lo hará, si requiere que establezca variables de entorno.
¿Hay un ''catch'' con FastFormat?
La última vez que lo revisé, hubo una captura molesta:
Solo puede usar la versión de cadena estrecha o la versión de cadena ancha de esta biblioteca. (Las funciones para wchar_t y char son las mismas, el tipo que se utiliza es un conmutador de tiempo de compilación).
Con iostreams, stdio o Boost.Format puedes usar ambos.
Aunque FastFormat es una buena biblioteca, hay varios problemas con ella:
- Soporte de formato limitado, en particular las siguientes características no son compatibles:
- Ceros a la izquierda (o cualquier otro relleno no espacial)
- Codificación octal / hexadecimal
- Especificación de ancho / alineación de tiempo de ejecución
- La biblioteca es bastante grande para una tarea relativamente pequeña de formateo y tiene una dependencia aún mayor (STLSoft).