Re: [boost] Warning policy? local variable hides (i.e. shadows) global variable

Subject: Re: [boost] Warning policy? local variable hides (i.e. shadows) global variable
From: Olaf van der Spek (ml_at_[hidden])
Date: 2015-01-18 11:52:07

On Fri, Jan 16, 2015 at 12:36 PM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> On Friday 16 January 2015 12:19:30 Olaf van der Spek wrote:
>> On Fri, Jan 16, 2015 at 4:46 AM, Gavin Lambert <gavinl_at_[hidden]>
> wrote:
>> > On 16/01/2015 06:22, Olaf van der Spek wrote:
>> >>
>> >> Ruby requires @ to access class members. I've been wondering, wouldn't
>> >> it be nice to have something like this in C++ as well?
>> >> "m_" and "_" would no longer be required.
>> >> Obviously this isn't a short-term solution.
>> >
>> > There *is* something like that in C++ -- you can prefix all member
>> > accesses
>> > with "this->".
>>
>> Right, but that's just ugly. :p
>>
>> > Of course, then you get yelled at by all the people who hate the added
>> > verbosity, because this is optional.  (And I don't disagree with them; and
>> > the pun was intended.)
>>
>> Next step would be to have warnings or maybe a per-class attribute or
>> modifier to make this required.
>
> I would really hate that, sorry.

Why?

>> > (And it doesn't help with function arguments, which is what was being
>> > discussed here.)
>>
>> Perhaps @@ for non-local stuff?
>> It might look silly at first but I think it's better than relying on
>> coding styles and prefixes.
>
> Right, let's add some more mangling to the already complicated C++ syntax.
>
> I think C++ name lookup rules are very sane and relying on them is the right
> thing to do. Just pick the right names and you'll be fine. In fact, the proper
> names will serve as documentation. Warnings about the code that does exactly
> what is intended is what irritates me in compilers. I often have to cripple
> the code just to make them happy and not myself. That's why I typically
> disable such warnings and not "fix" the code.
>
> There will always be room for stupid mistakes like "=" instead of "==" in
> conditions or a ";" right after the "for" operator or @ instead of @@ in your
> suggested syntax or whatever else. It doesn't mean that the language is
> broken. It means you have to pay attention.

Sure, but using a prefix or suffix for member variables is a common
practice. Do you not do it?

-- 
Olaf