¿Estilo de programación de declaración de método de get/set variables de método en C++?

Question

Debería declarar los getters/setters de la clase dentro del archivo .h y luego definirlos en .cpp o hacer ambos en el archivo .h. ¿Qué estilo prefieres y por qué? Personalmente me gusta el último en el que todos ellos están en .h y solo los métodos que tienen lógica asociada a él además de los setters/getters en .cpp.

Answer 1

Para mí, depende de quién va a utilizar el archivo .h. Si se trata de un archivo en gran parte interno de un módulo, entonces tiendo a poner los pequeños métodos en el encabezado. Si se trata de un archivo de encabezado más externo que presenta una API más fija, pondré todo en los archivos .cpp. En este caso, a menudo usaré el PIMPL Idiom para obtener un firewall de compilación completo.

Las compensaciones que veo con ponerlos en las cabeceras son:

• teclear menos procesos en línea
• más fácil para el compilador
(aunque los compiladores pueden a veces no inlining entre múltiples unidades de traducción ahora de todos modos.)
• Más dependencias de compilación

Answer 2

diría que los archivos de cabecera debe ser aproximadamente interfaz, no aplicación. Los pondría en el .cpp.

Answer 3

Casi siempre sigo la división de declararlos en el encabezado y definirlos en la fuente. Cada vez que no lo hago, termino teniendo que regresar y hacerlo de cualquier manera más tarde.

Answer 4

Pongo todas las líneas simples en el encabezado siempre que no requieran demasiados encabezados adicionales incluidos (porque los métodos de llamada de otras clases). Además, no trato de poner todo el código en una línea, así que puedo poner la mayoría de los métodos en el encabezado :-)

Pero Josh mencionó una buena razón para ponerlos en el .cpp de todos modos: si el encabezado es para uso externo.

Answer 5

Prefiero ponerlos en el archivo .cpp, por el bien de tiempos rápidos de compilación/enlace. Incluso los pequeños juegos de líneas simples (destructores virtuales vacíos) pueden explotar tus tiempos de compilación, si se instancian mucho. En un proyecto, pude reducir el tiempo de compilación en unos pocos segundos moviendo todos los destructores virtuales en los archivos .cpp.

Desde entonces, he vendido esto, y solo volvería a ponerlos en el encabezado si un generador de perfiles me dice que puedo sacar provecho de la alineación. El único inconveniente es que necesita más tipeo, pero si crea el archivo .cpp mientras escribe el encabezado, a menudo solo puede copiar & pegar las declaraciones y completarlas en el archivo .cpp, por lo que no es tan malo. Peor, por supuesto, si luego descubres que quieres mover cosas a un archivo .cpp.

Un buen efecto secundario es que leer cosas es más simple cuando solo tienes documentación y declaraciones en tu encabezado, especialmente si los nuevos desarrolladores se unen al proyecto.

Answer 6

Utilizo la regla siguiente: cabecera para declaración, archivo de código para su realización. Se convierte en real cuando su encabezado se utilizará fuera del proyecto - que más ligero es su encabezado, entonces es más cómodo en uso

Answer 7

Prefiero mantener el archivo .h lo más limpio posible. Por lo tanto, las funciones pequeñas que son tan simples como get/set utilizo a menudo para poner en un archivo separado como funciones definidas en línea, y luego incluir ese archivo (donde uso la extensión .inl) en el.h archivo de cabecera:

// foo.h 

class foo 
{ 
public: 
    int bar() const; 

private: 
    int m_bar; 
}; 

#include "foo.inl" 

// foo.inl 

inline 
int foo::bar() const 
{ 
    return m_bar; 
} 

creo que esto da lo mejor de dos mundos, al mismo tiempo, ocultando la mayor parte de la implementación de la cabecera, y aún así mantener la ventaja de inlining código simple (como una regla de oro Lo mantengo dentro de 3 declaraciones como máximo).

Answer 8

Para mí, esto depende de lo que esté haciendo con el código. Para el código que quiero mantenido y que perduran en el tiempo, puse todo en el archivo .cc por las siguientes razones:

• El archivo .h puede permanecer escasa como documentación para las personas que quieren lucir para la función y el método definiciones.
• Las pautas de codificación de mi grupo indican que ponemos todo en el archivo .cpp y nos gusta seguirlas, incluso si la definición de función solo tiene una línea. Esto elimina los juegos de adivinanzas sobre dónde viven realmente las cosas, porque sabes qué archivo debes examinar.
• Si realiza recompilaciones frecuentes de un proyecto grande, mantener la definición de la función en el archivo .cpp le ahorra algo de tiempo en comparación con mantener las definiciones de función en los archivos de encabezado. Esto fue muy relevante para nosotros recientemente, ya que recientemente revisamos el código y agregamos muchas declaraciones de afirmación de tiempo de ejecución para validar los datos de entrada de nuestras clases, y eso requirió mucha modificación para getters y setters. Si estas declaraciones de métodos hubieran vivido en archivos .cpp, esto se habría convertido en una recompilación limpia para nosotros, que puede tomar ~ 30min en mi computadora portátil.

eso no es para decir que no juego rápido y sucio con las reglas de vez en cuando y poner las cosas en .h al implementar algo realmente rápido, pero para el código que estoy serio sobre todo lo que el código (independientemente de la longitud) en el archivo .cpp. Para grandes proyectos (algunos de) las reglas están ahí por una razón, y seguirlas puede ser una virtud.

Hablando de eso, solo pensé en otra secuencia de comandos de Perl que puedo hackear juntos para encontrar violaciones de las pautas de codificación. Es bueno ser popular. :)