C++ ortodoxo (2016)

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

Reacción general a “Orthodox C++”

  • Muchos consideran que el artículo es superficial o dogmático: enumera prohibiciones en lugar de ofrecer orientación matizada o justificación.
  • Otros, especialmente de los ámbitos de videojuegos y sistemas embebidos, dicen que en gran medida refleja una práctica pragmática de larga data: subconjunto pequeño, sin RTTI/excepciones, stdlib limitada.
  • Varios señalan que C++ es inherentemente multiparadigma y que cada equipo serio ya elige su propio subconjunto; “orthodox” es solo otro estilo más.

C frente a C++ y la complejidad del lenguaje

  • Algunos programadores de C sostienen que C++ añade una gran carga mental: más comportamiento oculto, reglas de vida útil y “footguns” que C.
  • Otros responden que C ya tiene bastante complejidad oculta y UB; C++ al menos ofrece tipado más fuerte y mejores abstracciones.
  • Un tema recurrente: los ingenieros están ocupados resolviendo problemas de dominio y no quieren seguir cada nueva característica o versión de C++.

Características modernas: auto, range-for, RTTI, excepciones

  • El for basado en rangos con auto se defiende ampliamente por ser legible y menos propenso a errores que la plantilla repetitiva de iteradores.
  • Los críticos dicen que auto oculta tipos en revisiones de código y diffs; sus defensores responden que la inferencia de tipos es estándar en muchos lenguajes y que los IDE lo resuelven.
  • Prohibir RTTI y dynamic_cast se ve por algunos como innecesario; otros lo llaman un olor de código y prefieren RTTI manual o personalizada por rendimiento/control.
  • Las excepciones son muy controvertidas:
    • Los detractores citan imprevisibilidad, dificultad de depuración, preocupaciones de determinismo y contratos poco claros de “¿qué puede lanzar esta función?”.
    • Las voces favorables subrayan que están bien cuando se usan solo para violaciones verdaderamente excepcionales del contrato, no para el manejo rutinario de errores.

Biblioteca estándar, contenedores e I/O

  • Fuerte crítica a std::map, std::unordered_map, std::deque e incluso std::vector por rendimiento, comportamiento de caché, concurrencia y APIs incómodas.
  • Otros sostienen que son perfectamente adecuados para enormes cantidades de código real; los problemas surgen sobre todo en contextos extremos de alto rendimiento y baja latencia.
  • Los iostreams están ampliamente mal vistos; muchos prefieren printf al estilo C o las APIs más nuevas fmt/<format>. Algunos dicen que evitar iostreams sin dejar de usar formato con seguridad de tipos es el punto medio sensato.

Metaprogramación con plantillas y alternativas

  • Algunos celebran la metaprogramación pesada con plantillas y los estilos funcionales como algo excepcionalmente potente, sobre todo con los nuevos constexpr/consteval/concepts.
  • Otros se quejan de los tiempos de compilación y de los errores ilegibles, y abogan por un uso escaso.
  • Se mencionan repetidamente alternativas como Rust, Zig, Nim, D y enfoques de “mejor C”; cuando existe la opción, varios dicen que evitarían C++ por completo.