Beruflich Dokumente
Kultur Dokumente
1. Introduction
Use C++ with .NET. Microsoft supply a .NET C++ compiler that produces IL rather than machine code.
(To make full use of the .NET environment (e.g. garbage collection), a set of extensions are required to
standard C++, called C++/CLI.)
Each of these options has merits, depending on the developer and the application, but for most general
purpose applications C# is a much more productive environment than C++. Where existing C++ code must
be used with a new application, the existing code can be wrapped using C++/CLI to allow it to interop with
C#.
2. Types
2.2 Is it true that all C# types derive from a common base class?
Yes and no. All types can be treated as if they derive from object (System.Object), but in order to treat an
instance of a value type (e.g. int, float) as object-derived, the instance must be converted to a reference
type using a process called 'boxing'. In theory a developer can forget about this and let the run-time worry
about when the conversion is necessary, but in reality this implicit conversion can have side-effects that
may trip up the unwary.
2.3 So I can pass an instance of a value type to a method that takes an object as a
parameter?
Yes. For example:
class CApplication
{
public static void Main()
{
int x = 25;
string s = "fred";
DisplayMe( x );
DisplayMe( s );
}
static void DisplayMe( object o )
{
System.Console.WriteLine( "You are {0}", o );
}
}
2.4 What are the fundamental differences between value types and reference types?
C# divides types into two categories - value types and reference types. Most of the intrinsic types (e.g. int,
char) are value types. Structs are also value types. Reference types include classes, arrays and strings.
The basic idea is straightforward - an instance of a value type represents the actual data, whereas an
instance of a reference type represents a pointer or reference to the data.
The most confusing aspect of this for C++ developers is that C# has predetermined which types are
represented as values, and which are represented as references. A C++ developer expects to take
responsibility for this decision.
For example, in C++ we can do this:
int x1 = 3;
// x1 is a value on the stack
int *x2 = new int(3)
// x2 is a pointer to a value on the heap
2.5 Okay, so an int is a value type, and a class is a reference type. How can int be derived
from object?
It isn't, really. When an int is being used as an int, it is a value. However, when it is being used as an
object, it is a reference to an integer value (on the managed heap). In other words, when you treat an int as
an object, the runtime automatically converts the int value to an object reference. This process is
called boxing. The conversion involves copying the int to the heap, and creating an object instance which
refers to it. Unboxing is the reverse process - the object is converted back to a value.
int x = 3;
// new int value 3 on the stack
object objx = x;
// new int on heap, set to value 3 - still have x=3 on
stack
int y = (int)objx;
// new value 3 on stack, still got x=3 on stack and
objx=3 on heap
The problem with this method is that it will throw a NullReferenceException if called like this:
string s = null;
displayStringLength( s );
Of course for some situations you may deem a NullReferenceException to be a perfectly acceptable
outcome, but in this case it might be better to re-write the method like this:
void displayStringLength( string s )
{
if( s == null )
Console.WriteLine( "String is null" );
else
Console.WriteLine( "String is length {0}", s.Length );
}
but the alias only applies in the file in which it is declared. A workaround in some cases is to use
inheritance:
public class IntList : List<int> { }
3.1 Structs are largely redundant in C++. Why does C# have them?
In C++, a struct and a class are pretty much the same thing. The only difference is the default visibility level
(public for structs, private for classes). However, in C# structs and classes are very different. In C#, structs
are value types (instances stored directly on the stack, or inline within heap-based objects), whereas
classes are reference types (instances stored on the heap, accessed indirectly via a reference). Also
structs cannot inherit from structs or classes, though they can implement interfaces. Structs cannot have
destructors. A C# struct is much more like a C struct than a C++ struct.
Another difference is that virtual method calls within a constructor are routed to the most derived
implementation - see Can I Call a virtual method from a constructor.
Error handling is also somewhat different. If an exception occurs during construction of a C# object, the
destuctor (finalizer) will still be called. This is unlike C++ where the destructor is not called if construction is
not completed. (Thanks to Jon Jagger for pointing this out.)
Finally, C# has static constructors. The static constructor for a class runs before the first instance of the
class is created.
Also note that (like C++) some C# developers prefer the factory method pattern over constructors. See
Brad Wilson's article.
3.6 If C# destructors are so different to C++ destructors, why did MS use the same syntax?
Presumably they wanted C++ programmers to feel at home. I think they made a mistake.
4. Exceptions
Note, however, that this stack trace was produced from a debug build. A release build may optimise away
some of the method calls which could mean that the call stack isn't quite what you expect.
6. Miscellaneous
"fred" == "Fred"
// false
string.Compare( "fred", "Fred", StringComparison.CurrentCultureIgnoreCase ) ==
// true
For more control over the comparison, e.g. exotic features like width-sensitivity, consider using
System.Globalization.CompareInfo.Compare(), e.g.
CultureInfo.CurrentCulture.CompareInfo.Compare(
"fred", "Fred",
CompareOptions.IgnoreCase |
CompareOptions.IgnoreKanaType |
CompareOptions.IgnoreWidth
);
(Take a look at Charles Cook's NOptFunc project for easy command-line parsing.)
6.5 How can I make sure my C# classes will interoperate with other .NET languages?
Make sure your C# code conforms to the Common Language Subset (CLS). To help with this, add the
[assembly:CLSCompliant(true)] global attribute to your C# source files. The compiler will emit an error if
you use a C# feature which is not CLS-compliant.
However consider using this more aesthetically pleasing (but functionally identical) formatting:
using( obj1 )
using( obj2 )
{
...
}
will display:
True
True
However things are more complex for reference types. Generally speaking, for reference types == is
expected to perform an identity comparison, i.e. it will only return true if both references point to the same
object. By contrast, Equals() is expected to perform a value comparison, i.e. it will return true if the
references point to objects that are equivalent. For example:
StringBuilder s1 =
StringBuilder s2 =
Console.WriteLine(
Console.WriteLine(
new StringBuilder("fred");
new StringBuilder("fred");
s1 == s2 );
s1.Equals(s2) );
will display:
False
True
s1 and s2 are different objects (hence == returns false), but they are equivalent (hence Equals() returns
true).
Unfortunately there are exceptions to these rules. The implementation of Equals() in System.Object (the
one your class inherits by default) compares identity, i.e. it's the same as operator==. So Equals() only
tests for equivalence if the class author overrides the method (and implements it correctly). Another
exception is the string class - its operator== compares value rather than identity.
Bottom line: If you want to perform an identity comparison use the ReferenceEquals() method. If you want
to perform a value comparison, use Equals() but be aware that it will only work if the type has overridden
the default implementation. Avoid operator== with reference types (except perhaps strings), as it's simply
too ambiguous.
7. C# 2.0
instead of this:
Thread t = new Thread( new ThreadStart(ThreadFunc) );
Another minor but welcome addition is the explicit global namespace, which fixes a hole in namespace
usage in C# 1.x. You can prefix a type name with global:: to indicate that the type belongs to the global
namespace, thus avoiding problems where the compiler infers the namespace and gets it wrong.
Finally C# 2.0 includes some syntactic sugar for the new System.Nullable type. You can use T? as a
synonym for System.Nullable<T>, where T is a value type. As suggested by the name, this allows values
of the type to be 'null', or 'undefined'.
8. C# 3.0
Query expressions are just syntactic sugar - they resolve to standard method calls. For example the query
expression above can be rewritten as:
var results = nameList.Where(name => name.StartsWith("j"));
The argument to Where() is a lambda expression, which represents an anonymous method. However a
lambda expression is not just a more concise way to represent executable code - it can also be interpreted
as a data structure (known as an expression tree), which allows the expression to be easily analysed or
transformed at runtime. For example, LINQ-to-SQL makes use of this feature to transform C# queries to
SQL queries, which gives much better performance than a simple in-memory filtering of results (as offered
by DataTable.Select(), for example).
The Where() method shown above is an example of another new C# 3.0 feature: extension methods.
Extension methods allow extra methods to be 'attached' to an existing type - any type, even sealed types
or types you don't have the source code for. For example, the Where() method can be applied to any type
that implements IEnumerable<T>.
Another new feature of C# 3.0 is the var keyword, which allows the compiler to infer the type of a variable
from context, which is required for anonymous types but can be used with standard named types too:
var list = new List<string>() { "jack", "jill", "sue" };
with named types
var person = new { name = "jack", age = 20 };
// optional use
// anonymous type
These examples also demonstrate the new object initializer and collection initializer syntax.
Finally, there are implicitly typed arrays and auto-implemented properties:
var names = new [] { "jack", "jill", "sue" };
public string Name { get; set; }
backing field auto-generated
// implicitly string[]