2010-12-23 15 views
6

Cuando uso el idioma pimpl, ¿es una buena idea poner todas las definiciones de métodos dentro de la definición de clase? Por ejemplo:Poner todos los métodos en la definición de clase

// in A.h 

class A { 
    class impl; 
    boost::scoped_ptr<impl> pimpl; 
public: 
    A(); 
    int foo(); 
} 

// in A.cpp 

class A::impl { 
    // method defined in class 
    int foo() { 
     return 42; 
    } 

    // as opposed to only declaring the method, and defining elsewhere: 
    float bar(); 
}; 

A::A() : pimpl(new impl) { } 
int A::foo() { 
    return pimpl->foo(); 
} 

Por lo que yo sé, los únicos problemas con poner una definición de método dentro de una definición de clase es que (1) la aplicación es visible en los archivos que incluyen la definición de clase, y (2) el compilador puede hacer el método en línea.

Estos no son problemas en este caso ya que la clase se define en un archivo privado, y la inclusión no tiene ningún efecto ya que los métodos se llaman en un solo lugar.

La ventaja de poner la definición dentro de la clase es que no tiene que repetir la firma del método.

Entonces, ¿está bien? ¿Hay algún otro problema que tener en cuenta?

+0

¿Qué es un archivo __private__? – ezpz

+0

@ezpz: ese no es un concepto de C++. Es solo un archivo que los usuarios de la clase no # incluyen para que los cambios en la implementación no los afecten. – Amnon

+0

Esto es precisamente lo que solía hacer. Para mí, este método funcionó muy bien. –

Respuesta

3

Creo que respondió su propia pregunta: ambas soluciones son equivalentes.

Sin embargo, no estoy tan seguro de que 'la alineación no tenga ningún efecto ya que los métodos se llaman en un solo lugar': una llamada adicional podría cuando las funciones no están en línea. Pero lo más probable es que el compilador sea lo suficientemente inteligente como para optimizarlos lejos de las llamadas de reenvío de una línea en la clase externa.

Al final, creo que es solo una cuestión de gusto.

+0

Tienes razón.Quise decir que la línea no tiene un efecto * negativo *, por lo que es otro profesional para la definición en línea. – Amnon

1

Normalmente no agrego métodos a la clase interna de Impl, pero no veo ningún problema si defines los métodos en línea. Me parece mucho más legible que tener una declaración y definición separada.

0

Si el compilador enlista los métodos depende del compilador y de los parámetros pasados.

En el caso del idioma pimpl, no creo que importe si los métodos están definidos dentro del cuerpo del Imp o no. Personalmente, me gustan definidos fuera, porque es fácil ver lo que es realmente importante (como las variables de miembro y la lista de métodos).

2

Ventajas:

  • todo el código de la clase se localiza

Desventajas:

  • para las clases más grandes: Cuando se necesita desplazamiento, se hace más difícil saber a qué clase a la que pertenece la función.
  • Las dependencias se resuelven más fácilmente cuando las funciones residen después de todas las declaraciones de clase. De lo contrario, podría ser necesario que algunas declaraciones de clase se muevan después de otras y algunas funciones aún tengan que moverse después de la declaración de clase cuando haya dependencia mutua de las clases internas.
Cuestiones relacionadas