c++ - gcc-wadow es demasiado estricto?

compilation

Question

En el siguiente ejemplo:

class A
{
  public:
    int len();
    void setLen(int len) { len_ = len; } // warning at this line
  private:
    int len_;
};

gcc con -Wshadow emitirá una advertencia:

main.cpp:4: warning: declaration of `len'' shadows a member of `this''

La función len y el entero len son de diferente tipo. ¿Por qué la advertencia?

Actualizar

Veo que hay una gran variedad de cocinas, lo que significa "sombra". Y desde el punto de vista formal, el compilador también hace exactamente lo que significa.

Sin embargo, en mi humilde opinión, la bandera no es práctica. Por ejemplo, el modificador / getter idiom de uso común:

class A {
   void prop(int prop);  // setter
   int prop() const;     // getter

   int prop;
};

Sería bueno si hubiera un indicador de advertencia que no emita una advertencia en el caso, pero que avisará en caso de que "int a" oculte "int a".

Al agregar -Wshadow en mi código heredado, se emiten toneladas de advertencias, mientras que de vez en cuando descubro errores causados ​​por el problema de "sombreado".

No me importa cómo se llamará "-Wmuch_more_practical_and_interesting_shadow" o "-Wfoooooo".

Entonces, ¿hay otra bandera de advertencia de gcc que haga lo que describí?

Actualización 2

No solo yo piensa - La sombra de alguna manera no es un texto de enlace útil. No estoy solo :) Las verificaciones menos estrictas podrían ser mucho más útiles.

Answer 1

El hecho de que el parámetro tenga un tipo diferente de la función miembro no afecta al hecho de que el parámetro oculte la función miembro.

¿Por qué esperas que no haya una advertencia sobre esto?

Answer 2

Esto parece estar resuelto en nuevas versiones de GCC.

De la versión 4.8 del registro de cambios :

The option -Wshadow no longer warns if a declaration shadows a function declaration,
unless the former declares a function or pointer to function, because this is a common
and valid case in real-world code.

Y hace referencia a los pensamientos de Linus Torvalds sobre el tema: https://lkml.org/lkml/2006/11/28/253

Desafortunadamente, el compilador más nuevo del sistema integrado en el que estoy trabajando actualmente todavía está basado en gcc 4.6.

Answer 3

Hace exactamente lo que dice en la caja. Te advierte de la sombra.

Dentro de la función setLen , hay dos símbolos en el alcance que comparten el mismo nombre. len es el nombre de un parámetro de función, y también el nombre de una función.

Uno oculta el nombre del otro, por lo que cuando escribe un código que hace referencia a len , es posible que no obtenga el resultado que desea. Ya que le pidió al compilador que le advirtiera sobre los símbolos que se ocultan entre sí, esto es lo que le advierte.

Answer 4

No entiendo por qué insistes sólo en algunos tipos específicos de sombreado. Sombrear es sombrear, y sus peligros son los mismos, incluso si los tipos son diferentes e incluso si una variable oscurece una función, como en su caso. El peligro de seguir a la sombra es que el código podría hacer algo diferente de lo que su autor quería que hiciera.

Esto, por cierto, puede suceder fácilmente cuando una variable está siguiendo una función, ya que en C ++ la distinción entre las dos es mucho más delgada de lo que parece a primera vista.

Por ejemplo, aquí una variable sombrea una función.

struct L { 
  void operator ()(); 
};

struct A {
  void len();

  A(L len) {
    len();
    // Intended to call the member function. Instead got a call to the functor
  }
};

y creo que es bastante obvio que debido a la sombra del código podría hacer algo que el autor no tenía intención de hacer.

Answer 5

Sí, podemos ajustar esta advertencia para advertir solo cuando el sombreado puede ser peligroso. Por ejemplo, no sombrear para

void set (int what) .. int what () const ..

pero advierta sobre el sombreado de la variable local y el ejemplo de functor anterior.

Para ser más exactos, avise cuando el sombreado puede ser peligroso, cuando la intención del autor del código puede no ser clara. En el caso de un parámetro int y una función miembro con el mismo nombre, está claro que el autor no quiere que se llame al miembro cuando hace referencia al parámetro.

Considero que esta advertencia de sombra es una buena idea, muy útil, solo necesita un poco más de reflexión para no advertir sobre casos claros y perfectamente seguros. Por ejemplo, puedo vivir con los argumentos necesarios para tener un prefijo o algo así, pero prefiero nombres limpios y simples.