2009-11-25 13 views

Respuesta

5

En los compiladores de gcc (v4.1 y posteriores) esto no se podría compilar con "error: calificación adicional". ¡Por lo tanto, es una buena práctica no ponerlo allí!

Consulte here que describe la calificación adicional como C++ no legal.

+0

no solo gcc, cualquier compilador excepto visual studio. –

0

día G,

siempre pensé que ese tipo de identificador se utiliza sólo en la implementación y no era necesaria en la definición de clase.

Una declaración de la clase es

class InputRecord; 

Lo que tienes hay una definición de clase.

class InputRecord 
{ 
    /* Construtor */ 
    ... 
    RejectRecord(); 
    ... 
    /* Destructor */ 
} 

a continuación en el archivo .cpp que tiene la implementación

InputRecord::RejectRecord() 
{ 
    ... 
} 
+0

Incluso eso es lo que entiendo. Antes de tomar cualquier decisión sobre cambiar el programa, solo quiero confirmar mi comprensión. De todos modos, gracias por la respuesta :-) –

0

En general, no hay ningún caso en que la desambiguación proporcionada por la explícita InputRecord:: en su ejemplo de código es probable que sean nada aparte de redundante.

Si el código realiza manipulaciones complejas donde la clase específica es relevante (digamos que la pasa a una clase base que tiene una versión sombreada), entonces puede ayudar a la claridad del código hacerlo explícito.

Es un poco como usar this-> (o this. en C#/Java).

Personalmente eliminaría cualquier especificador redundante y encontraría otra forma de transmitir el mensaje.

+0

En realidad, creo que tanto C++ como Java deberían obligar a las personas a usar esto para las variables miembro, por lo que ya no tenemos que nombrar mValue, m_value, m_Value, value_ etc. –

+0

Tenemos que nombrarlos 'm ...'? : P Desde una perspectiva de Programación Funcional le gustaría pensar antes de usar el estado/Desde la perspectiva de OO, sería 'normal'. Para ciertos tipos de cosas, esto se vería * realmente * feo. Algunos 'estándares' de programación dicen que no hay prefijación, ya que debe estar claro desde el código si es miembro o param, lo cual está bien si estás escribiendo el código correcto. (Personalmente, no uso la notación húngara, pero me aferro al prefijo [con '_'] sabiendo que está mal. Detesto tener que prefijar 'this' en todas partes). Creo que este es un caso claro de que no hay una solución OSFA. –

0

En la definición de clase, solo uso identificadores de clase si tengo parámetros que se nombran de manera similar (o lo mismo) a miembros privados de la clase. Evita la ambigüedad y también hace que el código sea más fácil de leer al mismo tiempo. No puedo pensar en otro caso en el que necesites usarlo.

Cuestiones relacionadas