0

I'm not sure why this is happening - hoping someone can explain it!

I have a base class called BaseRequest with this in it:

protected int cartNumber;

I have a derived class, which inherits BaseRequest. It has a public field and constructor as follows:

public int currentCartNumber;

public ExtendedBaseRequest(int cartNumber)
{
   currentCartNumber = cartNumber;
}

Yes, I know it's a bit silly to have a parameter with the same name as the protected field in the base class, but I didn't notice it until now!

This compiles and runs, but the public currentCartNumber value in the derived class is not set as it uses the value from the base class, which is always zero as initialised.

Shouldn't the compiler moan about this because the declaration of cartNumber in the constructor's signature has the same name as the one in the base?

Looking forward to hearing from you.

greg84
  • 7,541
  • 3
  • 36
  • 45
  • Greg please edit your question and shorten the title, should be few words but you have put the whole paragraph in there! :D – Davide Piras Feb 18 '11 at 00:10
  • 4
    Sorry but I don't believe it.... Are you sure you aren't just passing 0 into the constructor. According to intellisense the compiler will use the parameter here. – James Gaunt Feb 18 '11 at 00:15
  • James is right, your conclusion is wrong. The field DOES get the value of the constructor parameter - test it in a simple console app. There must be something else going on. – jeroenh Feb 18 '11 at 00:16

3 Answers3

7

This compiles and runs, but the public currentCartNumber value in the derived class is not set as it uses the value from the base class, which is always zero as initialised.

That description does not match the code fragment you've provided. Please provide a complete short program that we can compile and run ourselves to repro the alleged behaviour.

Shouldn't the compiler moan about this because the declaration of cartNumber in the constructor's signature has the same name as the one in the base?

No, that's perfectly legal. It is illegal to have the same name declared twice in the same declaration space, but a base class and a formal parameter list have different declaration spaces.

We want it to be legal to do this:

class C
{
    int blah;
    public C(int blah) 
    {
        this.blah = blah;
    }
}
Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
3

Your analysis of what's happening is incorrect. There's something else going on here.

Are you sure that you're not passing 0 into the constructor?

The unqualified cartNumber will always refer to the parameter. The inherited field would need to be qualified with this or base.

In the code shown in the question, the statement currentCartNumber = cartNumber will assign the value of the cartNumber parameter to the currentCartNumber field.

LukeH
  • 263,068
  • 57
  • 365
  • 409
  • I'm going to take another look at this in the morning when I'm back at work, plus my RDP session has just died! Thanks so much for your help. – greg84 Feb 18 '11 at 00:25
-1

I would say you have no way to solve this, you can use this to force usage of local member but you have no way to specify you want to use the parameter.

either you rename the local protected member using smth like m_ or my prefixes or you change the parameter name.

see here:

How do you name constructor argument and member variables?

Community
  • 1
  • 1
Davide Piras
  • 43,984
  • 10
  • 98
  • 147
  • This isn't the problem; the OP's analysis is wrong: an unqualified `cartNumber` will always refer to the parameter; `base.cartNumber` (or `this.cartNumber`) will always refer to the inherited field. – LukeH Feb 18 '11 at 00:17
  • right, I was also surprised to read what was described above, now was reading the latest comments and I see it's of course as you also noticed. Thanks. – Davide Piras Feb 18 '11 at 00:19
  • This will work if the constructor parameter matches the name of a member I want to assign a value to, but actually the constructor parameter matches the name of a member I don't want to retrieve a value from. I don't mind renaming the parameter, I'm just wondering why the compiler didn't stress out about it, rather than me having to read it over and over until I noticed the problem. Something like "A local variable named 'x' cannot be declared in this scope because it would give a different meaning to 'x', which is already used in a 'parent or current' scope to denote something else" – greg84 Feb 18 '11 at 00:19
  • Woah people are quick on here! Please disregard that last comment! :) – greg84 Feb 18 '11 at 00:20
  • Greg, the compiler cannot tell you anything because by design using this. there would not be any issue and compiler cannot know you will not use this. – Davide Piras Feb 18 '11 at 00:23