Signature inconsistency

Given the following code.

Code:

---

class Base
{
  public:
          int fn (const int);
};
 
int Base::fn (int i)
{
  i = i + 2;
  int j = i * 2;
  return j;
}
 
int main ()
{
  Base b;
  int i = 7;
  int j = b.fn (i);
}

---

Notice the inconsistency in the member function declaration vs its definition.

I can compile the above code using either the Sun 5.8 compiler or the gnu compiler. Neither one gives an error, or even so much as a warning. Why?

Interestingly enough, if you compile and link in separate steps, or create a dynamic library out of the class portion of the code, and then attempt to link with the library, you do get undefined symbol results, which is what I would have expected when compiling and linking in one step.

A little background: The only reason this is being brought up is some developers around here discovered a problem very similar to this with our system when trying to build some new code. The thing that was interesting about their problem was that the code would compile and link (in separate steps) just fine in debug mode. But in no-debug mode the issue surfaced, which was a good thing because the obvious fix was to fix the signatures. My curiosity got the best of me so I attempted to duplicate their problem with some very simple code (as shown above). I've described what happens above, but what I've been unable to duplicate is the debug vs no-debug issue. If anyone has any thoughts on this latter issue, I'd be interested in hearing that too. Thanks.

Quote:

---

Neither one gives an error, or even so much as a warning. Why?

---

Because there can be no ambiguity, though I believe the opposite is more typically used: the parameter in the prototype is not declared const, but it is declared const in the implementation. The idea is that the user of the function does not care whether or not the parameter is const since either way due to pass by value it will not affect the caller's copy of the value. The implementor might care since it is a reminder that the value should not be modified.

Quote:

---

Originally Posted by laserlight

The idea is that the user of the function does not care whether or not the parameter is const since either way due to pass by value it will not affect the caller's copy of the value. The implementor might care since it is a reminder that the value should not be modified.

---

That's great except why does the compiler complain if compiling and linking are done in separate steps? Actually, I just discovered the Sun compiler complains, but not the gnu compiler. So it appears maybe this is an issue with the Sun compiler. That might also explain the inconsistency between debug and non-debug modes.

When passing by value, the const qualifier doesn't make a whole lot of difference. I wouldn't be surprised if different compilers handled that case differently.