Programming Language on UberMongoose

C# Value Types are Objects

Sun, 12 Jun 2016 16:12:24 +0530

Value types in C# are Objects, but they don’t behave exactly like Objects do. A part of the reason for this is that all value types are implicitly derived from System.ValueType.

public abstract class ValueType
{
    protected ValueType();
    public override bool Equals(object obj);
    public override int GetHashCode();
    public override string ToString();
}

But wait! Structs can’t derive from classes!

At first glance, this seems true. You can’t for example do this:

public class Animal { }
public struct Rat : Animal { }

The compiler wont let you. Yet if MSDN and the C# language specification itself is to be belived, all value types inherit from object across System.ValueType, but Int32 doesn’t seem to mention this fact in its definition.

A Short History of Sorting in C#

Sun, 20 Mar 2016 09:37:24 +0530

Recently, while reading Jon Skeet’s excellent book“C# in Depth” I came across the long and varied history of sorting in the C# language. It provides a tantalising view of how the language has evolved over the years. Apart from being a great example on C# in particular it’s also a good example on how languages have improved over the years to become more expressive, while maintaining backward compatibility with earlier versions.

C# Abstract Properties, Virtual Properties and Access Modifiers

Sun, 21 Feb 2016 16:14:33 +0530

Properties in C# are first class citizens, this means that they can be declared as abstract, virtual, private and protected. This is not the general use case though, most of the time properties are used to encapsulate fields.

class Customer
{
    public int Number { get; set; }
    public string Name { get; set; }
}
 
Customer customer = new Customer();
customer.Number = 9;
customer.Name = "Mrs Lovett's Pie Shop";

n the example above, auto implemented properties are used to aid encapsulation. The C# compiler automatically generates the fields used to store the properties and also the methods used for access. Externally, the properties look just like public fields but are actually implemented as methods. The setters and getters of a property can have different access modifiers.

Emulating Classical Inheritance in Javascript

Sun, 13 Jul 2014 11:03:43 +0530

Javascript isn’t a classical language. It’s prototypal, which is a bit like every object being a class in waiting. You can create graphs of objects where one object inherits from another, but the idea of classes doesn’t really exist.

This can be a drawback, specially with code encapsulation. It becomes difficult to hide private implementation details from public interfaces to the object because Javascript provides no native access modifiers. There is however a number of methods for simulating classical inheritance and encapsulation in Javascript while things nice and clean

C++ Constructors and Move Semantics

Sat, 12 Apr 2014 10:12:06 +0530

In order to do almost anything with a class in C++, you need to define a few constructors. If you don’t, depending on usage, the compiler will generate those constructors for you. For example, consider the following code:

class Person
{
public:
    string name;
    int age;
};

The above class does not explicitly define a constructor of any kind and if you don’t use the class at all, the compiler will just ignore it. However on the other hand if you do the following:

High Performance Code - Make No Assumptions

Sun, 18 Aug 2013 09:40:51 +0530

Concurrent bear – parallel fish

Often when writing high performance code one can fall into the trap of making assumptions about the nature of the problem. Donald Knuth said “Premature optimisation is the root of all evil”. If that is the case then prejudiced optimisation is the seed.

I learned the bitter lesson myself. Recently while building an architecture to support crunching what I thought was a moderately large amount of data I made the mistake of designing it with multiple threads of execution. At the beginning my rationale seemed quite sound as many have postulated that the performance gain to be had from single threaded execution of code is limited. The architecture that I was building involved a fast in memory key value store called Redis as one of it’s pieces. Unfortunately in the case of Redis the opposite was true. Because it’s often expensive to synchronise between threads and because in the normal use case for Redis the bottleneck was the network and not the CPU it’s authors decided to make it a single threaded application taking and serving requests off the wire one at a time. However it can handle multiple clients at a time, that is it is a program that supports concurrency but that’s not the same thing as parallelism.

The pImpl Idiom – Hiding Private Implementation Details

Thu, 17 Jan 2013 16:16:31 +0530

One key principle behind the design of classes is that of the encapsulation of the implementation from the clients using the code. Here a client is any bit of source code that uses the classes that you write. C++ provides an imperfect implementation of this idea in the way it defines rules for classes. Consider the following class which is declared in event.hpp.

#include "system_clock.hpp"
 
class Event
{
 
private: 
    SystemClock mClock;
    std::string mMessage;
 
public:
    Event(std::string message);
    ~Event();    
};

The Event class models an event that can happen at some point in time. It uses “system_clock.hpp” which defiles a class called SystemClock to see what time it is. Notice that both the message and the current time as defined by the member variable mClock in Event is private. This should mean ideally that any changes to the variables in the private section of the class is not exposed to the client code and indeed to an extent it is. No client can create an instance of Event and then access it’s private members like so:

Sociable Programming

Mon, 10 Dec 2012 10:42:43 +0530

Programmers are not known to be social creatures. It’s an unfortunate reputation really, considering that programmers spend most of their lives writing their thoughts to each other - they should be right up there in the social landscape with Paris Hilton and Lady Gaga. The problem of course is that programmers never recognise the social aspect of their work. They think they write code for computers. Nothing could be further from the truth.

Step on that Code

Sun, 02 Dec 2012 16:09:10 +0530

In Sociable Code I mentioned that an often overlooked consideration when writing code is the strain that it puts on the programmers who end up reading it. Difficult to read code tends to mash the wetware and end up causing more bugs and longer resolution times. One way to reduce that effort is to write code that would make control flow explicit when being stepped through with a debugger. Take a look at this bit of code. I came across it during a foray into a rather well known programming site. I have endeavoured to anonymise the code but the key piece has not lost it’s form.