Tag Archives: C#

Newbie Mistake — Object Equality

I made a newbie mistake.

This is similar to some code I just wrote. Can you spot the mistake?

(HINT: the code compiles; I made a logic mistake not a syntax mistake):

using System;
using System.Collections.Generic;

public class Program
{
static void Main(string[] args)
{
var d1 = new Dictionary<Foo, string>();
var key = "hi";
var foo = new Foo(key);

d1.Add(newFoo(key), "whatever");
Console.WriteLine("d1 key == d2 key? {0}", d1.ContainsKey(foo))
Console.ReadKey();
}
}

public class Foo
{
public Foo(string fooString)
{
_fooString = fooString;
}

public string FooString
{
get { return _fooString; }
}

// ...

private readonly string _fooString = "";
}


Answer:

The problem is with the ContainsKey() method on the d1 object (of type Dictionary).

I expected the result to be “true” because I was thinking that the VALUE OF THE KEY is the same for d1 and d2 (i.e. “hi”).  But what I forgot is that ContainsKey() is not testing for equality of the VALUE OF THE KEY, but for equality of the key itself (the key object).  And in this case, the key object for d1 is a DIFFERENT OBJECT than the key object for d2.

Note a slight subtly, when I refer to my mistakenly comparing the “value of the key” I am NOT referring to the value of the key/value pair.   I am referring to my mistakenly comparing the private literal member field (_fooString).

In pseudo-code: d1.key.stringValue == d2.key.stringValue BUT d1.key != d2.key

Therefore, ContainsKey() returns false.

Beginner Aside: A Dictionary is a mapping of key/value pairs.  Keys must be unique and each key maps to a value (often a value could be another data structure/object).  Dictionary data structures are commonly used when you are working with data that is not stored sequentially (unsorted) and need fast lookup times (at the small expense of data insertion/write times).   Compare this to a List, in which insertion is fast (just plot the new data on the end) but looking up data is slower because the list must be traversed sequentially until you find the data you are looking for.

Ref vs Out in C#

I am in the process of interviewing contractors at work right now and have had the opportunity to ask one of my favorite C# questions:

What is the Difference Between Ref and Out in C#?

To my continued surprise, I have yet to have an interview candidate answer correctly. When I confront them with the question, most candidates will start to confuse pass by reference with pass by value, even though I tell them that both keywords are used for pass by reference. Or they’ll tell me that they’ve used out in some methods but don’t know why.

Grant it — in my opinion, having both keywords is extraneous. In Java, all objects are passed by reference without distinction. Similarly, C++ does not distinguish between the means of reference. C# requires a keyword to pass by reference. But people get confused because there are TWO keywords and BOTH pass by reference.

My guess is that Microsoft probably assumed they were making life easier for the programmer by providing both keywords for pass by reference. The keyword distinction allows the .Net compiler to assure that an argument is initialized/set prior to passing it into the method in the ref case. Or initialized/set inside the method in the out case.

In other words, the difference is that ref requires that an argument be initialized BEFORE being passed into a method. out does not require prior initialization, BUT does require that the implementation of a method set or initialize the argument. BOTH words are used for pass by reference.

I will demonstrate the difference between ref and out by means of some code:

using System;

public class Program
{
   static void Main(string[] args)
   {
     var x = 5;
     PassByValue(x);
     Console.WriteLine("Result of PassByValue is: {0}", x);

     x = 5; // re-initialize to show nothing funny happening
     PassByRef(ref x);
     Console.WriteLine("Result of PassByRef is: {0}", x);

     x = 5; // not needed -- just for demonstration
     PassByOutRef(out x);
     Console.WriteLine("Result of PassByOutRef is: {0}", x);
   }

   static public void PassByValue(int x)
   {
     x += 5;
   }

   static public void PassByRef(ref int x)
   {
     x += 5;
   }

   static public void PassByOutRef(out int x)
   {
     x = 3; // required to re-initialize ds in order to compile
     x += 5;
   }
}

And here is the result:

Pass By Ref vs Out Result

Result of Pass by Ref vs Pass by Out Demo

Multiple Inheritence

Introduction

This post is about multiple inheritance in C++.

But I want to start by dispelling a myth: C# and Java have multiple inheritance too!  Yes,  in C# and Java you can only directly extend one concrete base class.  But in both languages you can implement as many interfaces as you want.  This limitation is designed to overcome some obstacles of the more flexible multiple-inheritance mechanism of C++.  But just because multiple inheritance in these C-derived languages is limited doesn’t mean it’s not existent.  As I will explain, multiple inheritance is important in object oriented design.

Advanced Aside: However, just because a class in any of these languages can extend one or more base classes, does not mean that it should.  Often composition is a better approach then inheritance.  This is especially true in situations where the derived class would need to hide or change the meaning of a function it is inheriting from a base class.  For example, in beginner software textbooks, the relationship between a shape and circles/squares is often used to demonstrate inheritance.  Simply put, a circle or square would seem to inherit from a shape.  But what if we were using a shape class developed by another programmer, who had already defined the shape class with a member function called GetLengthOfLargestSide().  Well, since circles don’t have sides, this method would be meaningless for circles.  So while it might be appropriate for a square class to inherit from this shape class, a circle class should not.

When Does Inheritance Make Sense?

  • Derived classes are going to exactly reuse previously defined methods in a concrete base class:  For instance, if we had two different classes, one for a square and one for a rectangle, rather then having to BOTH define a method to calculate area (length x height), they could inherit from a common, concrete base class that already implements this method once (such as a parallelogram class).
  • Polymorphism: another method requires passing a parameter of one of several types, but the exact type is not known until run-time.
  • Union of Features: This is the use case that requires the multiple inheritance mechanism of C++.  The limitations in modern managed languages like Java and C# prevent this feature of inheritance.  A union of features occurs when a base class inherits different properties from multiple parents.

For instance, here is a union of features:

class Mother
public:
     int MothersChromosomes() { return 23; }
     // ...
};

class Father
public:
     int FathersChromosomes() { return 23; }
     // ...
};

class Child : Mother, Father
public:
     int ChildsChromosomes() { return MothersChromosomes() + FathersChromosomes(); }
     // ...
};

Note in practice this is probably a lousy example of a proper use of inheritance.   Remember earlier I cautioned about using inheritance when the child (base class) needs to delete or hide something it inherits from its parents.  Well, in my example, it is unlikely the child class inherits both the male parts and female parts of its parents, so to speak, unless we are talking about slugs or snails….  so the child would need to arbitrarily hide (or =delete) on of these features..

Advanced Aside: Inheritance might make sense when derived classes share a common set of constant read-only fields to define “magic numbers”, such as the meaning of PI. But note that using this technique in interfaces may be considered a bad design decision, in part because it breaks the “is-a” paradigm for inheritance. In fact, for interfaces, using public constant fields works in Java, but not in C#. Specifically, in Java, interfaces may contain public static final variables. In C#, interfaces may not contain fields at all. Often a better choice in all languages (C++, C#, and Java) is to declare public static fields in concrete classes (such as the PI field in C#’s System.Math class) or to use enumerations.

The C++ Multiple Inheritance Super Happy Path:

When a C++ class inherits from multiple parents (or even multiple ancestors further up the inheritance hierarchy… e.g. grandparents), in which EVERY function is pure virtual and there are NO public or protected fields than the C++ programmer has nothing to worry about. This is essentially the equivalent of having multiple inheritance of interfaces in Java, C#, etc. Obviously this super happy path means forfeiting many of the benefits of inheritance (and multiple inheritance) so I am not suggesting this optimistic scenario is realistic.

Problem With Multiple Inheritance

Finally I get to the meat of my post. I will demonstrate the crux of the C++ multiple inheritance issue by example. You can imagine even more complex scenarios by extending this example (in particular, the clashes I am about to demonstrate could be higher up the inheritance hierarchy).

#include<string>

#include<iostream>
using namespace std;

class English
{
public:
     virtual string MyFavoriteColor() { return "blue"; }
};

class Japanese
{
public:
     virtual string MyFavoriteColor() { return "青"; }
};

class Woops : English, Japanese
{
public:
   void PrintFavoriteColor()
   {
      cout << MyFavoriteColor; // ERROR (ambiguous) -- is this English or Japanese?

   }
 };

Note, the proper way to fix this is to preface the class name and scope operator before the ambiguous call, e.g.:  

cout << Japanese::MyFavoriteColor;