[Octave-bug-tracker] [bug #48493] Clear up "shadowed member" warnings

[Lachlan Andrew]

Follow-up Comment #8, bug #48493 (project octave):

JWE, I'm still not quite sure what you want done.

Let's use the example of "exit_status" from
octave_exit_exception::octave_exit_exception(int, bool).

That class currently has a private member variable m_exit_status, a public
function exit_status, and (as if by accident) a parameter exit_status.

We can't rename the function m_exit_status, because that conflicts with the
member variable name.

We can make a potentially large change, and rename the member function to
something like get_exit_status, or we can make a small change to fix the
"accident" and rename the parameter, to something like p_exit_status.

I'm happy to do whichever you suggest (except the impossible one, which is how
I interpret your previous requests), but will argue below that changing the
parameter is the best approach.


First, I don't see why it is not a problem to have a parameter named the same
as a member function.  (I know this is something we cannot change...) 
Consider the code


class a
{
public:
  void (*callback) ();

  a (void (*default_callback) () )
  {
    if (default_callback == NULL)
      {
        // something long enough
        // to forget what parameter name I used
      }

    callback = default_callback;
  }

  void default_callback (void);
  void other_callback (void);
}

a  b(a::other_callback);


That is unambiguous to the compiler (which is why it is not an error), but
misleading (which is why it should be a warning).

We don't even need to have function-type variables.  Simply being told that a
call "exit_status ()" is invalid is misleading.


Second, if devs are using a version of gcc that doesn't warn of situations
like the above, then they are likely to create new constructors for existing,
possibly widespread, classes that cause this ambiguity.  A global policy of
changing the member name would require widespread changes to the code, to
essentially work around an accident.  (That doesn't mean we can't do it in
this particular case.)

Oh, and "_m" was just a typo.  Sorry for any confusion.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48493>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/