4 ms·

> Why are those warnings not automatically included in "-Wall -Wextra"? Not all of them are actually errors, maybe depending on your style. For example, shadow

> Why are those warnings not automatically included in "-Wall -Wextra"? Not all of them are actually errors, maybe depending on your style. For example, shadowing a variable is a well-defined feature of the C language, and so some code patterns take advantage of that fact. Other people avoid shadowing like the plague.

throwaway613834 9y ago
IMO shadowing is wrong in the same function and needs to be punished :) but "shadowing" other scores like base classes or class members or the is definitely okay, since you should be using a qualifier like foo:: or this-> to access them anyway.
- jhasse 9y ago
  > you should be using a qualifier like foo:: or this-> to access them anyway. I think a lot of C++ devs will disagree with this. It's also very uncommon from my experience. One could argue that this should be solved by semantic highlighting or naming conventions instead.
  - throwaway613834 9y ago
    Yeah, I would disagree with a lot of C++ devs on this. But I strongly stand by my opinion. First of all, it's not even a substitute. m_foo won't work if it's declared in a class based on a template parameter; you'll still need a qualifier. And suddenly that makes the code inconsistent, which in itself is kind of bad. Inconsistency makes it harder to read code and spot mistakes. And why should how you refer to a variable change based on the mere fact that the class containing it takes a template parameter? Second, there is really no good reason why you should have to change class C { C(int width) : value(width) { } int width; }; to class C { C(int width) : m_width(width) { } int m_width; }; Ambiguity? Not really. If you actually follow the convention of qualifying member variables with this-> or the like, nobody would ever get confused at whether the "x" in x = 1 refers to a local variable or to a member variable. Literally the only reason to do this is laziness in typing, and C++ was most definitely not designed to be the language for saving keystrokes. You just have to get that notion out of your system when using the language; it just leads to worse code (speaking from experience). Furthermore, there is no reason to encode the member-ness of a variable into its name. What's so special about that information? Should we start encoding the access specifiers too (private/public/etc.)? What about whether it's a class member? s_m_priv_width instead of just width? Why can't we just call the variable whatever darn thing it represents? And my tongue is halfway in my cheek here, but this feels akin to naming your American kid AmeriAlex instead of just Alex. What sense does that make? Finally, let's get semantic highlighting out of the way -- it fundamentally cannot with C++ syntax or with the C preprocessor, and it's twice as impossible with the two. It's never clear what m_foo refers to. Is it a global or is it in the base class? If it's in a header file included by two other .c files, and the preceding header files declare different base classes, what color should it have? It would refer to different things (maybe in one case in a namespace, and in another case in a class). Coloring is just an unsolvable problem in this language; it's not reliable in telling you where a variable referred to is declared.
    - jhasse 9y ago
      I agree with you, I also don't like these naming conventions. Still I don't use this-> and have never been bitten by a shadowed variable (yet). > class C { C(int width) : value(width) { } int width; }; You mean to write class C { C(int width) : width(width) { } int width; }; here, right?
cup-of-tea 9y ago
That's why they are warnings, not errors. You don't have to use -Werror...

throwaway613834 9y ago

IMO shadowing is wrong in the same function and needs to be punished :) but "shadowing" other scores like base classes or class members or the is definitely okay, since you should be using a qualifier like foo:: or this-> to access them anyway.

jhasse 9y ago
> you should be using a qualifier like foo:: or this-> to access them anyway. I think a lot of C++ devs will disagree with this. It's also very uncommon from my experience. One could argue that this should be solved by semantic highlighting or naming conventions instead.
- throwaway613834 9y ago
  Yeah, I would disagree with a lot of C++ devs on this. But I strongly stand by my opinion. First of all, it's not even a substitute. m_foo won't work if it's declared in a class based on a template parameter; you'll still need a qualifier. And suddenly that makes the code inconsistent, which in itself is kind of bad. Inconsistency makes it harder to read code and spot mistakes. And why should how you refer to a variable change based on the mere fact that the class containing it takes a template parameter? Second, there is really no good reason why you should have to change class C { C(int width) : value(width) { } int width; }; to class C { C(int width) : m_width(width) { } int m_width; }; Ambiguity? Not really. If you actually follow the convention of qualifying member variables with this-> or the like, nobody would ever get confused at whether the "x" in x = 1 refers to a local variable or to a member variable. Literally the only reason to do this is laziness in typing, and C++ was most definitely not designed to be the language for saving keystrokes. You just have to get that notion out of your system when using the language; it just leads to worse code (speaking from experience). Furthermore, there is no reason to encode the member-ness of a variable into its name. What's so special about that information? Should we start encoding the access specifiers too (private/public/etc.)? What about whether it's a class member? s_m_priv_width instead of just width? Why can't we just call the variable whatever darn thing it represents? And my tongue is halfway in my cheek here, but this feels akin to naming your American kid AmeriAlex instead of just Alex. What sense does that make? Finally, let's get semantic highlighting out of the way -- it fundamentally cannot with C++ syntax or with the C preprocessor, and it's twice as impossible with the two. It's never clear what m_foo refers to. Is it a global or is it in the base class? If it's in a header file included by two other .c files, and the preceding header files declare different base classes, what color should it have? It would refer to different things (maybe in one case in a namespace, and in another case in a class). Coloring is just an unsolvable problem in this language; it's not reliable in telling you where a variable referred to is declared.
  - jhasse 9y ago
    I agree with you, I also don't like these naming conventions. Still I don't use this-> and have never been bitten by a shadowed variable (yet). > class C { C(int width) : value(width) { } int width; }; You mean to write class C { C(int width) : width(width) { } int width; }; here, right?

cup-of-tea 9y ago

That's why they are warnings, not errors. You don't have to use -Werror...