Actually, m_ for members and g_ for globals helps quite a bit while reading a lot of unknown code.
The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed. Forget or neglect to rename the variable and now you've got misleading information.
Any kind of extra encoded information in a variable name can be omitted or out of date by mistake; that holds regardless of convention. I don't feel that's a strong enough argument against the practice. I would argue that if the scope of a variable has changed, then its semantics have changed enough to warrant a rename.
A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals. The compiler can then help you by catching incorrect usage.
I didn't know you could ask the compiler to flag members accessed without an explicit this-> and full namespace qualification of symbols within the current namespace. How does one do so? Without that compiler enforcement, using this-> and full namespace qualification are just more conventions...