Subject: Re: [boost] Warning policy? local variable hides (i.e. shadows) global variable
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-01-16 06:36:24
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]>
> > 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.
> > (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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk