Si estoy creando una clase con pequeñas funciones que no hacen mucho, ¿es aceptable simplemente ponerlas todas en el archivo de encabezado? Entonces, para una clase en particular, solo es el .h sin .cpp.(C++) ¿Toda la clase en el archivo .h?
Sí, eso es aceptable. Ciertamente compilará. Pero también, si hace que la organización del código sea más limpia, eso puede ser bueno. La mayoría de las definiciones de plantilla ya son así por necesidad, por lo que no está haciendo nada inaudito. Sin embargo, puede haber algunos inconvenientes de que la clase dependa de otras clases. Si termina teniendo que incluir toda la definición en otros archivos que usan la clase, puede incurrir en tiempo de compilación adicional en comparación con solo tener una breve declaración de clase.
Puede medir sus tiempos de compilación si esto parece ser una preocupación real.
Si puede obtener una copia, The c++ Programming Language (y muchos otros libros) tienen una sección detallada sobre la organización del código fuente y los beneficios específicos de separar el código en archivos .h y .cpp.
Sí, es aceptable. Además, si hace plantillas y no tiene un compilador con soporte export, entonces no tiene otra opción.
Sin embargo, tenga en cuenta que puede aumentar las dependencias y hacer que la compilación sea más lenta.
Estaría bien si va a utilizar ese archivo de encabezado en sus futuros códigos o proyectos, y si desea compartirlo con los demás.
Depende de cómo se está vinculando. Para evitar tener que ver mensajes como la redefinición de bla, la definición anterior en el archivo blah.h en la línea 13 simplemente coloca todo excepto la declaración en un archivo .cpp.
Depende de lo que está buscando.
Para un proyecto de mascota, es aceptable, pero todo es realmente.
Para un proyecto real, usted tiene que preguntarse una serie de preguntas:
Si las respuestas lo satisfacen, entonces continúe.
Es principalmente una cuestión de gestión de la dependencia. Al poner la definición de métodos dentro del encabezado, es probable que el compilador los agregue, lo que significa que cada vez que cambien, tendrán que volver a compilar todo lo que dependa de esta clase.
Las plantillas lo hacen, sin embargo, las plantillas generalmente tienen pocas dependencias (otras incluyen) y usted está relativamente obligado a proceder de esa manera (aunque puede externalizar código que no depende de la plantilla para reducir las dependencias).
Para grandes proyectos reales donde la gestión de la dependencia es primordial, entonces desaconsejaría. En esos proyectos, un ABI estable y la capacidad de promover cambios binarios compatibles son salvavidas en caso de problema y valen la pena el inconveniente "leve" para el desarrollador.
En cualquier caso, no defina los métodos en el medio de la clase. Incluso en línea, puede definirlos después de la declaración de clase. Esto hace que sea más fácil para las personas que lo leen (usted mismo en unos pocos meses) obtener rápidamente la interfaz.
IMO, si sus métodos son en su mayoría de una sola línea, tener una definición de método dentro de la clase realmente no distrae mucho y en ocasiones puede aumentar la comprensibilidad del código; y de hecho, la única razón por la cual alguien no quisiera crear un archivo .cpp separado es porque la clase es pequeña y los métodos son triviales. –
@Lie Ryan: Estoy de acuerdo en que las líneas simples (como 'empty' /' size') pueden definirse en el medio de la clase sin molestar demasiado ... pero luego es difícil definir el límite entre una y otra. liner, una línea que está envuelta porque no cabe en la pantalla, una línea doble que es más corta que la línea enrollada, ... Después de eso, todos llaman. –
Pero no necesita definir un límite estricto, simplemente siga sus instintos. Al final, el compilador todavía produciría la misma salida o salida equivalente. Muchas guías de estilo de programación promueven el estilo consistente simplemente porque la consistencia es fácil de cuantificar, si algo siempre se ve igual, entonces es consistente; sin embargo, en muchos casos, esta obsesión por la coherencia se produce a costa de ignorar los beneficios potenciales que son difíciles de cuantificar. La legibilidad y la comprensión no es tan fácil de cuantificar; y como resultado, a menudo se alinean lateralmente en las pautas de estilo. –