Datasheet

6
Part I: Design Strategies
http://www.softsteel.co.uk/tutorials/cSharp/lesson2.html and http://blogs.msdn.com/
ericgu/archive/2005/01/26/360879.aspx
):
Both languages compile into machine-independent byte code that runs in a managed environ- ❑
ment. Although the .NET Framework runs exclusively on Windows today, you can run the C#
Intermediate Language (IL) code on other platforms such as Linux using alternative environments
such as Mono (
http://www.mono-project.com/Main_Page).
Memory errors occur less often because both languages rely on garbage collection to manage ❑
memory.
You can view the internal workings of applications created with either language using refl ection. ❑
Applications have less code because neither language requires that you use header fi les. ❑
Using classes is less cumbersome because classes are scoped to packages or assemblies. In addi- ❑
tion, you don’t have to worry about the order in which classes appear in the application. Classes
also descend from objects and you allocate them from the heap using the
new keyword.
It’s possible to lock threads with ease, providing superior thread synchronization. ❑
A class can contain another class to provide inner classes. ❑
Some potential runtime errors are avoided by eliminating global variables — every variable ❑
is part of a class. In addition, both languages provide bounds checking for arrays and strings,
making some types of application bugs exploitable by virus writers a thing of the past.
Both languages rely on the ❑
. operator to separate object elements. You no longer need to worry
about whether to use the
:: or -> operators.
Both languages provide full support for the ❑
null and boolean/bool keywords.
The managed environment automatically initializes all values before use, so you won’t have any ❑
of those mystery values from C++ pop up.
All conditional statements rely on a Boolean comparison, rather than using ❑ integer values directly .
Try ❑ blocks provide support for a Finally clause that lets you perform cleanup even if a code
sequence fails, which should help eliminate memory and state problems.
This list isn’t meant to provide you with a complete comparison between C#, Java, and C++, but it does
illustrate that there are important issues to consider as part of defi ning the language environment for
your application. You may fi nd situations where C++, despite its defi ciencies, is still the language of choice
for a particular situation. Knowing the defi ciencies of each language in your arsenal is important
because this knowledge helps you make the right language choice.
Unsafe Code Capability
The Common Language Runtime (CLR) constantly monitors everything your managed application does,
which makes the code more reliable. CLR considers managed code safe because you can’t do things like
add pointers together or perform other kinds of pointer arithmetic found in older languages such
as C/C++. In the past, using pointers led to all kinds of problems, including memory corruption,
so modern applications generally don’t perform direct pointer manipulation. In fact, direct pointer
manipulation doesn’t work with .NET applications because the garbage collector constantly changes
the pointer addresses (which is the reason you must pin and unpin
IntPtr managed pointers when
making P/Invoke calls).
15962c01.indd 615962c01.indd 6 1/23/09 5:44:59 AM1/23/09 5:44:59 AM