Duplicate declaration
-
I ran into this yesterday:
public class Aaaaaargh { string _nameToBeStored = ""; //Constructor public Aaaaaargh() { string _nameToBeStored = "Some text for example"; } //Property public string WhatsTheName { get { return _nameToBeStored; } } }Property WhatsTheName always returns ""; This simplified example shows a warning and it's obvious what the problem is but the real error gave me no compiler warnings as i was carrying out several operations on the local variable before leaving the constructor. Who could ever think that it might be a good idea to allow a local variable to hide an instance variable without even giving a warning at compile time? Russell -
I ran into this yesterday:
public class Aaaaaargh { string _nameToBeStored = ""; //Constructor public Aaaaaargh() { string _nameToBeStored = "Some text for example"; } //Property public string WhatsTheName { get { return _nameToBeStored; } } }Property WhatsTheName always returns ""; This simplified example shows a warning and it's obvious what the problem is but the real error gave me no compiler warnings as i was carrying out several operations on the local variable before leaving the constructor. Who could ever think that it might be a good idea to allow a local variable to hide an instance variable without even giving a warning at compile time? RussellFrankly speacking, if such warning exist I'll probably disable it... Local object hinding much global ones is a principle that every stuctured language more or less has... and its normal for who writes in a local scope to don't care of global object he's not interested into. The point is another: if your original attempt was to initialized
_nameToBeStored, why the hell did you re-declared it as local? (I thing the wordstringdid't materilize by itself... it's not a forgotten "=" or ";") In general, my point is that warnings should warn about ambiguos statements or behavior, rather then clear programming mistake. In the most of the case what you did is perfectly normal and making sense. Apart this bug. But it's your bug, not a compiler misinterperted ambiguity.2 bugs found. > recompile ... 65534 bugs found. :doh:
-
Frankly speacking, if such warning exist I'll probably disable it... Local object hinding much global ones is a principle that every stuctured language more or less has... and its normal for who writes in a local scope to don't care of global object he's not interested into. The point is another: if your original attempt was to initialized
_nameToBeStored, why the hell did you re-declared it as local? (I thing the wordstringdid't materilize by itself... it's not a forgotten "=" or ";") In general, my point is that warnings should warn about ambiguos statements or behavior, rather then clear programming mistake. In the most of the case what you did is perfectly normal and making sense. Apart this bug. But it's your bug, not a compiler misinterperted ambiguity.2 bugs found. > recompile ... 65534 bugs found. :doh:
originally i had declared the variable and initialised it to a fixed value while the class was being developed. When i copied the initialising code into the ctor i had left the word string in the statement. While i accept that truly global variables should be hidden by locals, i would never have expected an instance variable to be hidden by a local variable in a method of its own class. I agree that it is my bug but it was very irritating to find out what the problem was. I would love to be able to switch this delight off as I can ever think of an instance where i would want to benefit fromt his kind of hiding. Russell
-
originally i had declared the variable and initialised it to a fixed value while the class was being developed. When i copied the initialising code into the ctor i had left the word string in the statement. While i accept that truly global variables should be hidden by locals, i would never have expected an instance variable to be hidden by a local variable in a method of its own class. I agree that it is my bug but it was very irritating to find out what the problem was. I would love to be able to switch this delight off as I can ever think of an instance where i would want to benefit fromt his kind of hiding. Russell
Sorry Russell, I completely disagree with you. The rules of the C++ standard are attempting to to be as consistent as possible. Your suggestion for a compiler behaviour would actually add one more rule. And if you introduce that rule you would also have to decide about how to handle this fully legal case: void MyClass::Func() { int iLocal = 0; DoStuffWith( iLocal ); { int iLocal = 0; // this is another iLocal DoStuffWith( iLocal ); } DoMoreStuffWith( iLocal ); // the original iLocal is still alive in this scope } But: even if you disagree on my and Emilio's view of the C++ language, I think it is a very naughty idea to name local variables the same way as class members. You should strongly enforce a naming convention that tells the reader if a variable is local or not just by its very name. IMHO :)
_____________________________________ Action without thought is not action Action without emotion is not life
-
Sorry Russell, I completely disagree with you. The rules of the C++ standard are attempting to to be as consistent as possible. Your suggestion for a compiler behaviour would actually add one more rule. And if you introduce that rule you would also have to decide about how to handle this fully legal case: void MyClass::Func() { int iLocal = 0; DoStuffWith( iLocal ); { int iLocal = 0; // this is another iLocal DoStuffWith( iLocal ); } DoMoreStuffWith( iLocal ); // the original iLocal is still alive in this scope } But: even if you disagree on my and Emilio's view of the C++ language, I think it is a very naughty idea to name local variables the same way as class members. You should strongly enforce a naming convention that tells the reader if a variable is local or not just by its very name. IMHO :)
_____________________________________ Action without thought is not action Action without emotion is not life
I was working in C# but i guess the same rules should apply for both languages. I certainly never intended to name the variable the same in the method and the class. Careless use of copy/cut and paste meant that the variable got declared in the method when what i wanted was to set the value of the instance variable. Russell
-
Sorry Russell, I completely disagree with you. The rules of the C++ standard are attempting to to be as consistent as possible. Your suggestion for a compiler behaviour would actually add one more rule. And if you introduce that rule you would also have to decide about how to handle this fully legal case: void MyClass::Func() { int iLocal = 0; DoStuffWith( iLocal ); { int iLocal = 0; // this is another iLocal DoStuffWith( iLocal ); } DoMoreStuffWith( iLocal ); // the original iLocal is still alive in this scope } But: even if you disagree on my and Emilio's view of the C++ language, I think it is a very naughty idea to name local variables the same way as class members. You should strongly enforce a naming convention that tells the reader if a variable is local or not just by its very name. IMHO :)
_____________________________________ Action without thought is not action Action without emotion is not life
C# does not allow that. you can't have a variable in a nested scope with the same name as a variable in the parent scope. the compiler gives an error. but, it does allow you to hide a member variable inside a function. the compiler only gives a warning.
image processing toolkits | batch image processing | blogging
-
I was working in C# but i guess the same rules should apply for both languages. I certainly never intended to name the variable the same in the method and the class. Careless use of copy/cut and paste meant that the variable got declared in the method when what i wanted was to set the value of the instance variable. Russell
I've done this -- you go to copy the variable name and accidentally grab the type part ("string" in this case) as well. Like you, I've spent time trying to figure out what the heck went wrong! It's one of the things I'm very careful to avoid now. I think you just gained experience. :-D
-
C# does not allow that. you can't have a variable in a nested scope with the same name as a variable in the parent scope. the compiler gives an error. but, it does allow you to hide a member variable inside a function. the compiler only gives a warning.
image processing toolkits | batch image processing | blogging
Chris, I understand the synthesis, but you ended by mixing-up different concepts. One thing is the language (a “set of specifications”) and another is the compiler (a “product implementing that specification in a given context”) So “C# does not allow that. you can't have a variable in a nested scope with the same name as a variable in the parent scope” is a fact that descend from the language, but “the compiler gives an error.” Is a consequence of the compiler implementation. Again “it does allow you to hide a member variable inside a function” is a language specification, but “the compiler only gives a warning.” is an implementation consequence This –in your only context- is only a pedant distinction, but related to the original context (“should a compiler gives a warning in the case a perfectly legal statement had been erroneously typed”) is fundamental: the language say it is legal, and the compiler should “read the programmer mind” to understand “what whashe originally trying to do”. It seems to me this goes a bit ahead of a compiler scope. Consider this:
int a(0);
while(a = somefunc())
{
do_something_with(a);
}I don’t feel good to receive a warning (like “assignment in a wile expression: is this what you intended ? ") since this makes seem “errored” a perfectly legal and wanted code. The result is a need for a
#pragma warning(disable: ...)(thus compromising portability) or to more “criptical” expression likewhile(!!(a = somefunc()))(the !! is at all effect an int-to-bool prseudo-operator)2 bugs found. > recompile ... 65534 bugs found. :doh:
-
Chris, I understand the synthesis, but you ended by mixing-up different concepts. One thing is the language (a “set of specifications”) and another is the compiler (a “product implementing that specification in a given context”) So “C# does not allow that. you can't have a variable in a nested scope with the same name as a variable in the parent scope” is a fact that descend from the language, but “the compiler gives an error.” Is a consequence of the compiler implementation. Again “it does allow you to hide a member variable inside a function” is a language specification, but “the compiler only gives a warning.” is an implementation consequence This –in your only context- is only a pedant distinction, but related to the original context (“should a compiler gives a warning in the case a perfectly legal statement had been erroneously typed”) is fundamental: the language say it is legal, and the compiler should “read the programmer mind” to understand “what whashe originally trying to do”. It seems to me this goes a bit ahead of a compiler scope. Consider this:
int a(0);
while(a = somefunc())
{
do_something_with(a);
}I don’t feel good to receive a warning (like “assignment in a wile expression: is this what you intended ? ") since this makes seem “errored” a perfectly legal and wanted code. The result is a need for a
#pragma warning(disable: ...)(thus compromising portability) or to more “criptical” expression likewhile(!!(a = somefunc()))(the !! is at all effect an int-to-bool prseudo-operator)2 bugs found. > recompile ... 65534 bugs found. :doh:
?? :~ there are two cases: one where a variable is declared at class scope and hidden by a local; and the other case, where a variable is declared local and hidden by another variable in an inner scope. one is illegal in C# and one generates a warning. there's no "mind reading" here. there's just two different reactions by the same compiler, written by the people who presumably designed the language in the first place, to two very similar constructions.
image processing toolkits | batch image processing | blogging
-
Frankly speacking, if such warning exist I'll probably disable it... Local object hinding much global ones is a principle that every stuctured language more or less has... and its normal for who writes in a local scope to don't care of global object he's not interested into. The point is another: if your original attempt was to initialized
_nameToBeStored, why the hell did you re-declared it as local? (I thing the wordstringdid't materilize by itself... it's not a forgotten "=" or ";") In general, my point is that warnings should warn about ambiguos statements or behavior, rather then clear programming mistake. In the most of the case what you did is perfectly normal and making sense. Apart this bug. But it's your bug, not a compiler misinterperted ambiguity.2 bugs found. > recompile ... 65534 bugs found. :doh:
emilio_grv wrote:
why the hell did you re-declared it as local? (I thing the word string did't materilize by itself... it's not a forgotten "=" or ";")
That's why it's a subtle bug! "bug" because it was put in there by the developer, and "subtle" because it's not always easy to see this issue until runtime. I agree with the OP - I've wanted a warning like this for a long time too!
www.IconsReview.com[^] Huge list of stock icon collections (both free and commercial)
-
I ran into this yesterday:
public class Aaaaaargh { string _nameToBeStored = ""; //Constructor public Aaaaaargh() { string _nameToBeStored = "Some text for example"; } //Property public string WhatsTheName { get { return _nameToBeStored; } } }Property WhatsTheName always returns ""; This simplified example shows a warning and it's obvious what the problem is but the real error gave me no compiler warnings as i was carrying out several operations on the local variable before leaving the constructor. Who could ever think that it might be a good idea to allow a local variable to hide an instance variable without even giving a warning at compile time? RussellRussell Jones wrote:
Who could ever think that it might be a good idea to allow a local variable to hide an instance variable without even giving a warning at compile time?
I wondered that too :confused: I've wanted a warning like this for a long time too!
www.IconsReview.com[^] Huge list of stock icon collections (both free and commercial)
-
?? :~ there are two cases: one where a variable is declared at class scope and hidden by a local; and the other case, where a variable is declared local and hidden by another variable in an inner scope. one is illegal in C# and one generates a warning. there's no "mind reading" here. there's just two different reactions by the same compiler, written by the people who presumably designed the language in the first place, to two very similar constructions.
image processing toolkits | batch image processing | blogging
Chris Losinger wrote:
one is illegal in C# and one generates a warning
Yes... but in my intentions this is an excessive synthesis: The two facts are: "one is illegal and the other not" (in the language spec. scope) "one gets and error and the other a warning" (in the compiler implementor scope) I can easilly think to a compiler not generating such warning and respecting the spec. Of course this becomes the same if you're using one and only compiler for a given language. To come back to the origin, my point is: this is not a subtle bug, since it doesn't descend from a compiler bug, library bug, documentation misinterpretetion or ambiguty etc. It's just a regular (not subtle) programmer bug, originating from a wrong statement in a wrong place.
2 bugs found. > recompile ... 65534 bugs found. :doh: