Why a C++ Developer May Find it Uneasy to Work With C#

Let me put up a disclaimer first, since the title of the article may contradict with the views of the C# developer community. This article is based on my own experience working on both C++ and C# languages for more than 4 years. And this article is intended for developers migrating from any flavors of C++ technology to C#. Also, a C# developer may look upon this article to get a picture of how distinct and abstract C# language design is when compared to other programming languages which run natively on hardware.

This article is highly abstract, which looks only into syntax and semantics of the languages, and doesn't really dig deeper into design considerations of the language.

So, let's quickly get to the point. How is C# distinct from C++?

One of the prime goals of C# language design is to get rid of ugly pointers and make coding easy, quick, clean which finally conduces "Rapid Application Development". But believe me, a C++ developer feels at home working with pointers, it's no real fun coding in the absence of pointers. In fact, a matured C++ developer finds it really hard to write programs deprived of pointers.

Not to be demotivated, Microsoft bequeathed every single responsibility of 'pointers' in the hands of " References " which basically alludes pointers. The message is clear... Microsoft doesn't expect or allow developers to mess around by having direct memory access.

The .NET Framework further makes developers' life easy or rather I say lazy by, completely managing the memory allocations and deallocations in the name of "Garbage Collection" and branding the resultant code as " Managed Code". What I really don't understand is that when an experienced developer can write complex algorithms, can design systems involving multilevel difficulties, is it really hard be responsible for memory management.

By delegating memory management to framework, a developer really loses flexibility on design and functioning of the system. If a developer had the luxury of memory management as in C++ he could clearly circumscribe on the target hardware capabilities and limitations on which the program will be run. And could also customize applications to be run on platforms constrained by hardware limitations.

The basic principle of Object Oriented Programming conveys that "Class represents a generic blueprint of an instance and values of data members are specific to an instance, but 'static' is an exemption here. Contrary to this, C# language design allows developers to assign initial value to data members of a class as shown below.

public class Student
{
   public string Name = " James Frank " ; 
}

ANSI standards for Object Oriented language implementation ensures initialization of data members of a class to default values through default constructor. If we already have a default constructor which is clean, and serving the main purpose, C# feature of member value assignment inside class definition is "Redundant" and affects code readability. Any feature of a language unless it serves a signification purpose is redundant or burden.

C# developers must be aware of the fact that it is possible to explicitly convert a value type variable to reference type, and a reference type variable to value type through a feature called Boxing and Unboxing respectively.

Boxing

short S = 20 ;
object ShortObject  = S ;

Unboxing

short S = (short) ShortObject ;

C# provided this feature to have a unified type system in place which allows value type to represent the underlying data altogether wrapped in a new representation called " reference " and vice versa. Unless there is a flaw in design, how the polymorphic classes are built this feature is of no worth, and if at all one is using this feature, it necessitates the need to trace back derivation hierarchy of polymorphic classes.

This is an odd feature of C#, it breaks the basic understandings of Object Oriented Programming in being developer friendly. Below is an example of static constructor:

public class employer
{
      private static string CompanyName ;
      static employer()
     {
         CompanyName = "Nokia" ;
     }
}

Static constructor ensures that static data members are always assigned to an initial value. And it is called, when an instance of class is created or a static member function is invoked.

I mentioned this is an odd feature because, this is a workaround for C# language design which doesn't allow anything to be defined outside of a class. In the absence of this constraint, static data members could have been defined and initialized outside class definition as in C++.

string employer :: CompanyName = "Nokia" ;

C# has introduced couple of enhancements in parameter passing mechanisms, to cut short developer efforts from writing lengthy code. Out of which out and ref are the two parameter decorators. Value for out parameter is assigned by the called member, as shown below:

public static void Add ( int x, int y, out int ans )
{
     ans = x + y ;
}

Usage

public static void calculate()
{ 
     int ans ;
     add ( 1, 2, ans ) ;
}

The sum is stored in ans variable by callee add.

Now consider the ref decorator, the only difference is ref parameter must be initialized before being sent to callee. So if this is the only constraint we don't really need out parameter at all, all which is required is to use ref, ensuring that the variable is assigned to initial value.

• Absence of Pointers
• Memory Management
• Member Value Assignment Inside Class Definition
• Boxing and Un-Boxing
• Static Constructors
• Redundant Out and Reference Parameters

These are a couple of features of C# which I found redundant, ugly, which lead to confusion, and mystify the clarity of the language rather than assisting a developer. However, these are my own views, but not conclusions.