By default, all parameters are passed by value in C#. Parameters are only passed by reference if you explicitly include an out or ref modifier. However, you need to be aware that when the type of the parameter is a reference type,
Although C# doesn’t have templates, and isn’t likely to get them, it is getting a feature called generics which will be available in the next version of .NET and Visual Studio. Generics will be a feature in the CLR itself, and most languages targetting the CLR will change to support it.
Many people, including the C# language designers, believe that ‘with’ often harms readability, and is more of a curse than a blessing. It is clearer to declare a local variable with a meaningful name, and use that variable to perform multiple operations on a single object,
The choice between C# and VB.NET is largely one of subjective preference. Some people like C#'s terse syntax, others like VB.NET's natural language, case-insensitive approach. Both have access to the same framework libraries. Both will perform largely equivalently (with a few small differences which are unlikely to affect most people, assuming VB.NET is used with <code>Option Strict</code> on). Learning the .NET framework itself is a much bigger issue than learning either of the languages, and it's perfectly possible to become fluent in both - so don't worry <i>too</i> much about which to plump for. There are, however, a few actual differences which may affect your decision: <h5>VB.NET Advantages</h5><ul> <li>Support for optional parameters - very handy for some COM interoperability</li> <li> Support for late binding with <code>Option Strict</code> off - type safety at compile time goes out of the window, but legacy libraries which don't have strongly typed interfaces become easier to use. </li> <li> Support for named indexers (aka properties with parameters). </li> <li> Various legacy VB functions (provided in the <code>Microsoft.VisualBasic</code> namespace, and can be used by other languages with a reference to the <code>Microsoft.VisualBasic.dll</code>). Many of these can be harmful to performance if used unwisely, however, and many people believe they should be avoided for the most part. </li> <li> The <code>with</code> construct: it's a matter of debate as to whether this is an advantage or not, but it's certainly a difference. </li> <li> Simpler (in expression - perhaps more complicated in understanding) event handling, where a method can declare that it handles an event, rather than the handler having to be set up in code. </li> <li> The ability to implement interfaces with methods of different names. (Arguably this makes it harder to find the implementation of an interface, however.) </li> <li> <code>Catch ... When ...</code> clauses, which allow exceptions to be filtered based on runtime expressions rather than just by type. </li> <li> The VB.NET part of Visual Studio .NET compiles your code in the background. While this is considered an advantage for small projects, people creating very large projects have found that the IDE slows down considerably as the project gets larger. </li> </ul><h5>C# Advantages</h5><ul> <li> XML documentation generated from source code comments. (This is coming in VB.NET with Whidbey (the code name for the next version of Visual Studio and .NET), and there are tools which will do it with existing VB.NET code already.) </li> <li>Operator overloading - again, coming to VB.NET in Whidbey.</li> <li> Language support for unsigned types (you can use them from VB.NET, but they aren't in the language itself). Again, support for these is coming to VB.NET in Whidbey. </li> <li> The <code>using</code> statement, which makes unmanaged resource disposal simple. </li> <li> Explicit interface implementation, where an interface which is already implemented in a base class can be reimplemented separately in a derived class. Arguably this makes the class harder to understand, in the same way that member hiding normally does. </li> <li> Unsafe code. This allows pointer arithmetic etc, and can improve performance in some situations. However, it is not to be used lightly, as a lot of the normal safety of C# is lost (as the name implies). Note that unsafe code is still managed code, i.e. it is compiled to IL, JITted, and run within the CLR. </li> </ul><p> Despite the fact that the above list appears to favour VB.NET (if you don't mind waiting for Whidbey), many people prefer C#'s terse syntax enough to make them use C# instead.
[Author: Jon Skeet]
There are two versions of the C# specification – one from Microsoft, and one from ECMA. They are the same in all important respects (a few pieces of explanatory wording are different, but nothing that affects the specification itself) but the numbering of sections is different.
Section 10.9.2 of the language specification says:
A binary operator must take two parameters, at least one of which must have the class or struct type in which the operator is declared. Parameters of the shift operators (§7.8) are further constrained.
In C++, I can define a macro such as:
#define PRODUCT(x, y, z) x * y * z
and then use it in code:
int a = PRODUCT(3, 2, 1);
C# doesn’t allow you to do this. Why?
There are a few reasons why.
In C#, when you specify a “using” clause, such as
the compiler only imports the types in System.Text into the global namespace – it doesn’t do the same with any namespaces inside of System.Text. So, while that using allows me to write:
StringBuilder s = new StringBuilder();
Some languages provide a power operator, so one can write something like:
float result = value^2;
rather than having to resort to calling. We don’t have one in C#.
It would be possible to add a power operator to the language,
This answer is from Chris Brumme via the following post. I’ve copied the text in here in case the post disappears.
There are a number of reasons we don’t implement Multiple Implementation Inheritance directly. (As you know, we support Multiple Interface Inheritance).