This question already has answers here:
Why doesn't the C# compiler stop properties from referring to themselves?
(6 answers)
Closed 9 years ago.
Accidentally I created a bug in my work. The cause of the bug is a snippet of c# code like
public ClassA{
public string AProperty
{
get
{
return AProperty;
}
set
{
AProperty = value;
}
}
}
You can build that, and running that without any exceptions.
But it will create an infinite loop. For example, while setting the AProperty, it always tries to assign the value to its self.
Anyone knows why in C# the compiler will allow this syntax?
Because the C# compiler team didn't decide to make this exact case illegal. Possibly because they didn't consider the benefits of implementing it to be greater than the costs.
It's something that comes up with even the most trivial amount of testing; it's not a very subtle bug, and it's something that developers learn to look for if they get bitten by it a few times.
Related
This question already has answers here:
C# Empty Statement
(13 answers)
Closed 5 years ago.
I've come across this example of an empty statement in a C# textbook.
Code:
public void empty()
{
;
}
Some quick googling found that it's a redundant feature and I can't see the use of this as it seems pointless?
I was curious to know when this would've been useful and if it's still used to date even though it's obsolete?
In the given example it is pointless and/or cosmetic.
The empty statement is "useful" in places where a statement is required but you have nothing to do, like
while (condition_with_side_effects) ;
Because of the side effects required, this will not match with most coding guidelines or best practices.
Consider it a leftover from C.
This question already has answers here:
What is the difference between const and readonly in C#?
(30 answers)
Closed 6 years ago.
I come from a C++ background and am trying to become proficient in C#. It seems like C# always has 2 types of modifiers wherever C++ had one. For example, in C++ there is & for references and then in C# there is ref and out and I have to learn the subtle differences between them. Same with readonly and const, which are the topic of this thread. Can someone explain to me what the subtle differences are between the 2? Maybe show me a situation where I accidentally use the wrong one and my code breaks.
Readonly: Can only be set in the constructor.
Const: Is a COMPILE TIME CONSTANT. I.e. can not be determined at runtime.
This question already has answers here:
What does the => operator mean in a property or method?
(7 answers)
Closed 7 years ago.
I came across this in our code-base today, and it took me awhile to see what the effect of it was, but what in the world does this actually mean??
public virtual SomeClass InstanceVariable => new SomeClass("arg1", "arg2");
I played around with this in Visual Studio's C# interactive terminal and discovered that it appears to be equivalent to:
public virtual SomeClass InstanceVariable { get { new SomeClass("arg1", "arg2"); } }
However, I couldn't find any documentation on this being any form of 'syntactic sugar' for a read-only property.
Someone want to shed some light on the scenario?
It is from new C# 6.0. You can instantiate your class by default. Check "Expression Bodied Functions and Properties" of https://msdn.microsoft.com/en-us/magazine/dn802602.aspx article
This question already has answers here:
Setting Objects to Null/Nothing after use in .NET
(15 answers)
Closed 8 years ago.
I don't mean to start a[nother] civil war over this issue, but should nullification be enforced or not?
While trying to fix a bug (that was fixed elsewise, as can be seen here), I added code like this in a couple of places to immediately and explicitly set some objects to null:
List<String> XMLFiles = CCRUtils.GetXMLFiles(fileType, #"\");
foreach (string fullXMLFilePath in XMLFiles)
{
RESTfulMethods.SendXMLFile(fullXMLFilePath, uri, 500);
}
XMLFiles = null;
Now that I know that did not solve the problem I was having, should I just leave it, or remove this type of code?
should nullification be enforced or not?
In general, it should not. There are very few circumstances where there is a reason to set a variable to null. As soon as the scope in which the variable is declared ends, the reference to the object will no longer be held.
Setting a variable to null after use is (almost) always just a misunderstanding of how the GC works, and serves no purpose.
This question already has answers here:
Is there a generic constructor with parameter constraint in C#?
(9 answers)
Closed 8 years ago.
I wonder, what rationale is behind lack of generic class type constraints for typed constructors? eg.
public class MyClass<T>
where T : new(int)
{
public T Create(int i)
{
return new T(i);
}
}
Despite fact, that this may be quite easily (though IMO ugly) bypassed (by lambda-ctor), I can imagine no situation, when this constraint might cause any actual trouble or ambiguities.
Notice, that this is a language-structure question, not about a specific problem.
I searched a little bit and found an answer. But since it is here on SO and I don't want to copy it, I will just post a link. It is an answer from Eric Lippert. I hope his answers means something to you.
https://stackoverflow.com/a/9741812/809009
It is somewhat long question there, but you can skip it and read only linked answer.