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

Let me put up disclaimer first, since the title of article may contradict with the views of 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 to 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 is C# language design when compared to other programming languages which runs 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 C# is highly distinct from C++ ?

 

•  Absence of Pointers

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 a deprived of pointers .

Not to be demotivated , Microsoft bequeathed every single responsibly 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.

• Memory Management

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 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.

• Member Value Assignment Inside Class Definition

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.

• Boxing and Un-Boxing 

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.

 

• Static Constructors

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 work around 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 initialised outside class definition as in C++

 

string employer :: CompanyName = "Nokia" ;

 

• Redundant Out and Reference Parameters

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 "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.

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