Encontré este artículo proponiendo un estilo de codificación en c ++ que al principio parece un poco extraño. Pero después de leerlo y reflexionar un poco, realmente estoy considerando intentarlo.
El beneficio más atractivo es la facilidad de refactorizar los métodos. Me encuentro cambiando constantemente los nombres de los métodos, los parámetros, etc. mientras escribo una nueva clase y en c ++ es bastante molesto tener que cambiar el nombre de un método en dos archivos (.h, .cpp).
Traté de encontrar algo mal con este estilo, pero aparte del hecho de que el código se verá y se sentirá realmente extraño para los programadores experimentados de c ++, no puedo detectar ningún defecto importante. Pero dado que soy un programador de c ++ bastante inexperto, espero que alguien aquí pueda alertarme sobre cualquier peligro potencial.
Entonces mi pregunta es:
¿Hay algún inconveniente serio al usar este estilo de codificación?
fuente
struct B
en el ejemplo a una plantilla y se compiló muy bien.Respuestas:
Sí, vas a confundir a otros programadores de C ++ si escribes todo tu código así. Nunca he visto código C ++ sin plantilla escrito de esa manera, con todo en el archivo de encabezado. Esto también se ha discutido en profundidad en una pregunta de Stack Overflow .
En cuanto a los problemas técnicos reales con él, algunas cosas me vienen a la mente.
inline
. Sus tiempos de compilación probablemente aumentarán.También es posible que desee consultar el lenguaje de programación D , que según tengo entendido resuelve muchos de estos problemas. El compilador D está diseñado con este estilo en mente y no tiene 30 años de compatibilidad con C para admitir.
fuente
No es exactamente una idea nueva. Los programadores principiantes evitan declaraciones como la peste, y en su mayoría se salen con la suya porque sus programas son muy pequeños. La consecuencia es que ahora debe preocuparse por el orden en que define sus funciones. La consecuencia de preocuparse por el orden de definición es la tentación de minimizar el problema al hacer que sus funciones sean demasiado grandes.
También pierde la agradable separación de la interfaz y la implementación. El propio autor lamenta que los miembros privados formen parte del archivo de encabezado, luego "resuelve" el problema al hacer que todos los detalles de implementación formen parte del archivo de encabezado.
fuente
Si quieres clases de estilo Java, ¡entonces programa en Java !
Él hace muchas conjeturas en su artículo que son completamente erróneas. En ningún orden particular:
Esto es simplemente incorrecto, y muestra que nunca ha trabajado en un programa C ++ a gran escala. Descargue cualquier programa grande de código abierto de C ++, compile el programa y dígame si desea esperar tanto tiempo cada vez que olvida un punto y coma.
Ok, en primer lugar, no es una característica que "muy pocos programadores parecen conocer". En segundo lugar, se trata de un malentendido completo de la declaración adelantada y para qué se utiliza. La guía de estilo de codificación de Google tiene una introducción bastante decente: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Forward_Declarations
Están destinados a simplificar el compilador y reducen sustancialmente el tiempo de compilación.
fuente
Me parece que solo estoy dando un nombre tonto para hacer declaraciones en lugar de hacerlo
#include <blah>
.Los beneficios de las declaraciones adelantadas es que sus tiempos de compilación pueden ser significativamente más rápidos, pero el principal inconveniente de IMO es que debe tener en cuenta cuándo puede y no puede salirse con una declaración adelantada, y cuando la arruina, puede obtener mensajes de error aparentemente incomprensibles para un error trivial.
fuente