Bibliotecas C++ sensatas

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo proyecto, “Sane C++ Libraries”, pretende ofrecer un ecosistema alternativo y ligero para C++ sin STL, con tiempos de compilación más rápidos, abstracciones más simples y utilidades prácticas como E/S asíncrona, JSON y reflexión. Los comentaristas están divididos: algunos celebran el enfoque minimalista, el manejo explícito de errores y la evitación de excepciones, RTTI y punteros inteligentes, mientras que otros argumentan que despreciar la biblioteca estándar empeora la fragmentación y sacrifica componentes maduros y bien optimizados. El intercambio pone de relieve tensiones de larga data en C++ entre rendimiento, simplicidad, portabilidad y dependencia de la biblioteca estándar frente a bases personalizadas o de terceros.

Objetivos generales y posicionamiento

  • La biblioteca aspira a modelar un “mundo C++ alternativo” más parecido a Python/Node/Zig/C: funcionalidad práctica, E/S asíncrona, abstracción de plataforma, binarios más pequeños, sin excepciones/RTTI/stdlib.
  • El autor enfatiza la diversión, la simplicidad y centrarse en el “95% de los casos de uso” en lugar de cada caso límite.
  • Algunos lo ven como un punto intermedio entre el C inseguro y el libstdc++ recargado; otros consideran que “sin stdlib / sin excepciones / atomics personalizados” no es, por definición, “sensato”.

Evitación de la stdlib y fragmentación del ecosistema

  • Varios comentaristas objetan que ignorar la STL garantiza más fragmentación y peor interoperabilidad; ya les cuesta lidiar con cada biblioteca C++ definiendo sus propios tipos String/Vector.
  • Otros sostienen que STL tiene lastre de diseño y compatibilidad (por ejemplo, vector<bool>, mapas estándar, std::regex, plantillas pesadas, compilaciones de depuración lentas) y que muchos proyectos serios ya implementan su propia biblioteca central.
  • Comparación con Abseil: Abseil complementa la STL, mientras que este proyecto intenta reemplazarla en su mayor parte.

Contenedores, algoritmos y estructuras de datos

  • Se considera que el conjunto actual de contenedores está incompleto; la falta de conjuntos, colas, deques y hash maps de estilo estándar es un bloqueo para algunos.
  • Algunos usuarios dependen mucho de stack/deque; el autor es escéptico respecto al deque y prefiere soluciones basadas en vector y contenedores al estilo arena.
  • La biblioteca de “algoritmos” muestra actualmente bubbleSort en primer lugar; esto provocó críticas, y el autor aclaró que es un marcador de posición y que se ampliará con el tiempo.

Gestión de memoria, punteros inteligentes y excepciones

  • El proyecto omite deliberadamente SharedPtr/UniquePtr, basándose en un principio contra muchos pequeños objetos en heap y contra la propiedad compartida o poco clara.
  • Algunos discrepan firmemente, quieren punteros inteligentes para todos los objetos en heap y los ven como herramientas de seguridad de sobrecoste cero o bajo.
  • Otros describen patrones que usan vectores/arenas, handles y grupos de propiedad claros en lugar de punteros inteligentes.
  • Debate mayor: muchos comentaristas defienden C++ sin excepciones (a menudo con tipos estilo ErrorOr) como algo común y práctico; otros insisten en que C++ “no puede ser libre de excepciones” en ningún sentido significativo, argumentando que todo manejo de errores sigue siendo “excepciones disfrazadas”.
  • Entre las preocupaciones sobre las excepciones de C++ se incluyen coste no nulo, RTTI, flujo de control oculto, comportamiento de lanzamiento poco claro a partir de las firmas de función y el fomento de código centrado solo en el “happy path”.

Atomics y cuestiones de bajo nivel

  • Los atomics personalizados son cuestionados dado que std::atomic está profundamente ligado al modelo de memoria de C++.
  • La regla de no usar stdlib es la razón inmediata; el autor insinúa un posible indicador futuro opcional para usar encabezados estándar donde estén disponibles.

Sistema de compilación y macros

  • Se critica que describir compilaciones en C++ no sea “sensato”; los argumentos a favor de lo declarativo citan escalabilidad y simplicidad.
  • El autor responde que herramientas “declarativas” populares (por ejemplo, CMake) en realidad son DSLs imperativos.
  • A algunos les disgusta el uso de macros del proyecto por no ser “sensato”; el autor señala que la mayoría de las macros son cambios de plataforma, con macros opcionales en reflection.