Re: Parameter Name Warning?

From: Adam Clauss (cabadam_at_tamu.edu)
Date: 04/13/04 

Date: Tue, 13 Apr 2004 14:22:36 -0500

Just for clarification, Victor made that comment, not I. But I do agree with you on it. While as far as compilation is concerned
the names on the declarations do not matter, it should perhaps give a warning regarding different names being used.
The C++ standard may not require those names to be the same (or to exist in the declaration at all), but it does not require us to
use the exact same types in numerical expressions either. And we get a warning for those:
Ex:
int x = 5;
double y = 7.743;
unsigned long z = x + y;

That code is perfectly LEGAL, but we get a warning about it, as we probably should. We should also get a warning about parameter
names being misnamed as well. Not an error for sure, but a warning would be worthwhile. 

-- 
Adam Clauss
cabadam@tamu.edu
"Michael Kennedy [UB]" <mkennedy@REMOVETHIS.unitedbinary.com> wrote in message news:%23LzgynYIEHA.1220@tk2msftngp13.phx.gbl...
> Hi Adam,
>
> I want to follow up on another issue you raised below.
>
> You said:
>
> > > Note that parameter names are _irrelevant_ here.  Just like in any other
> > > function _declaration_.  They are (a) of no importance to the compiler
> > > and (b) ignored.
>
> There is still an issue with this that is *not* ignored by Visual Studio.
> First, I am aware that the compile disregards the parameter names here. But
> there is more to those names than just what the compiler does with them.
>
> Take the most extreme case: Consider a class exported out of a DLL. That is,
> a class were you have no knowledge of the implementation parameter names.
> You know only what you get in the header. Suppose that the class developer
> swapped the variable names in the header but not the implementation by
> mistake. Consumers of that class only see the header and will program
> against it using the variable names indicated there. If the swapped types
> are the same type (like char *'s in my example), then they will be sending
> invalid data to the method.
>
> To make matters worse, the VS.NET intellisense comes from the header, not
> the implementation. So when those parameters are swapped, VS.NET encourages
> you to use the method incorrectly.
>
> This is why I think there should be a compiler warning when it is clear that
> the parameters are mismatched (swapped around).
>
> Regards,
> Michael
>
> "Adam Clauss" <cabadam@tamu.edu> wrote in message
> news:ecMwCMYIEHA.2876@TK2MSFTNGP09.phx.gbl...
> > I just wrote up a similar test program on VS 2003.  Variable values were
> correct for me in the watch window.
> > f and localF were both 5; e and localE were both 6.
> >
> > Verified that they were all correct in the auto, local, and Watch 1
> windows.
> >
> > -- 
> > Adam Clauss
> > cabadam@tamu.edu
> >
> > "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
> news:eifX$jXIEHA.2244@TK2MSFTNGP09.phx.gbl...
> > > Michael Kennedy [UB] wrote:
> > > > I recently spend too long tracking down a bug in a project I'm working
> on
> > > > using VC++ and VS.NET 2003 that I think could have easily been avoided
> if
> > > > the VC++ compiler could have reported a warning. Here's the problem:
> > > >
> > > > I have a typical C++ class (call it class A) defining a member method
> (call
> > > > it method M) with the definition defined in the header and the
> > > > implementation defined in the cpp file. But two of the parameters got
> their
> > > > order switched *only* in the definition but not in the implementation.
> In
> > > > code that is:
> > > > -----------------------------------------
> > > > class A
> > > > {
> > > > public:
> > > >    void M(int a, int b, int c, int d, int e, int f); // note e, then
> f.
> > >
> > > Note that parameter names are _irrelevant_ here.  Just like in any other
> > > function _declaration_.  They are (a) of no importance to the compiler
> > > and (b) ignored.
> > >
> > > > };
> > > >
> > > > void A::M(int a, int b, int c, int d, int f, int e) // note f, then e.
> > > > {
> > > >    int localE = e;
> > > >    int localF = f;
> > > >    // ...
> > > > }
> > > > -----------------------------------------
> > > >
> > > > Obviously my values weren't named a,b,c, ... so the reversed order
> wasn't so
> > > > apparent. Plus, the method took many parameters so it wasn't that easy
> to
> > > > notice. But what was worse was when debugging into the method with the
> > > > debugger, the watch window showed different values for e and f than
> they
> > > > actually had!
> > >
> > > That is VERY HARD to believe.  Could you provide a screen shot?  Are you
> > > sure you didn't have _local_ variables named 'e' and 'f' that _hid_ the
> > > values of the parameters?
> > >
> > >  > So, consider only f in this scenario. Suppose we called method
> > > > M like this M(1, 2, 3, 4, 5, 6). Then f will have the value f = 5. But
> in
> > > > the watch window f = 6!
> > >
> > > REALLY?  Are you sure it's not a figment of your imagination?
> > >
> > >  > Now if you step through the code to the // ... line,
> > > > in the watch window you get:
> > > >
> > > >    localF = 5
> > > >    f = 6
> > > >
> > > > How about that to drive you crazy! That is, immediately after the line
> > > >
> > > >    int localF = f;
> > > >
> > > > executes, you get localF = 5, f = 6 in the watch window!
> > >
> > > What product is that, again?  I have VC++6sp5 and the watch window is
> fine.
> > >
> > > I took the code you posted, wrote a tiny driver and got this:
> > > --------------------
> > > class A
> > > {
> > > public:
> > >     void M(int a, int b, int c, int d, int e, int f); // note e, then f.
> > > };
> > >
> > > void A::M(int a, int b, int c, int d, int f, int e) // note f, then e.
> > > {
> > >     int localE = e;
> > >     int localF = f;
> > >     // ...
> > > }
> > >
> > > int main()
> > > {
> > >      A a;
> > >      a.M(1,2,3,4,5,6);
> > >      return 0;
> > > }
> > > --------------------
> > >
> > > Then I build a Debug version and stepped into the 'A::M' function.  My
> > > watch window showed 'f' as 5 at the very beginning and then later
> 'localF'
> > > as 5 as well.
> > >
> > > >
> > > > So here's where I think the compiler could have saved me. If it
> realized
> > > > that both in the definition and implementation of the method I use
> exactly
> > > > the same parameter names, but they are swapped around, it could have
> warned
> > > > me about that.
> > >
> > > It could.  What about warning you if you misspelled something in your
> > > comments?  Or should the IDE do that instead?  Wouldn't it be silly?
> > >
> > > >
> > > > I realize that I could have defined the method as void M(int, int,
> int, int,
> > > > int, int); and the compiler wouldn't be able to say anything. But
> since I am
> > > > actually using the same names a,b,c,d,e,f in both the definition and
> > > > implementation and they don't match, I think a warning could be in
> order.
> > > >
> > > > Also, the debugger could have helped. If the debugger got it's
> parameter
> > > > definitions from the implmentation rather than the definition as the
> C++
> > >
> > > I cannot imagine it would do that.  (BTW, it's definition and
> declaration,
> > > not "implementation and definition")  And again, I cannot imagine MS
> screw
> > > up so badly (well, actually, I can, but I am fairly certain there would
> be
> > > a patch for that already).
> > >
> > > > runtime/compiler does, then I would have at least noticed that the
> incoming
> > > > parameters e and f had the wrong values. It would have avoided the
> crazy int
> > > > localF = f; => localF != f in the watch window.
> > > >
> > > > What do you (especially Microsoft C++ guys) think?
> > >
> > > I think you're looking in the wrong place.  I tried reproducing what you
> > > described and couldn't.  Of course, I'm using version 6 of VC++.  Is
> that
> > > what you use?  If not, forgive my not trusting you, and take my advice:
> > > call MS Technical Support.  If their debugger is so buggy itself, they
> > > need to take care of it.
> > >
> > > Victor
> > > -- 
> > > Please remove capital As from my address when replying by mail
> >
> >
>
>

Relevant Pages

  • Re: is order urgent doubt
    ... Which *compiler* are you using? ... layout of the warning messages.) ... i = sizeof(long int); ... about the code in the editor vs. the code in the source file. ...
    (comp.lang.c)
  • Re: Parameter Name Warning?
    ... there is more to those names than just what the compiler does with them. ... You know only what you get in the header. ... correct for me in the watch window. ... >> int main ...
    (microsoft.public.vc.language)
  • Re: Compendiums of compiler warning/error messages mapped to actual code problems?
    ... The general problem is of course that the compiler messages must be short, and that tends to make them so cryptic that it isn't always immediately obvious what the problem is. ... int this; ... Warning twarn.c: ...
    (comp.lang.c)
  • Re: Whats the deal with size_t?
    ... ES> allowed to emit diagnostics that C doesn't require. ... in warning about a signed to unsigned conversion. ... a size_t to an int it is quite justified in warning about the reverse, ... The compiler is also quite justified in warning if you use a signed ...
    (comp.lang.c)
  • Re: matrix stuff (solving b = A*x) --> using numerical recipes
    ... but then I removed it since I couldn't see any compiler warnings/errors without stdio.h). ... turn the warning level up to the maximum ... void banmul(float **a, unsigned long n, int left, int right, float x, float b); ...
    (comp.lang.c)