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.

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?