Why write Unit tests

One of the reasons we don't refactor our code is that we are afraid that it might break something. But, if you have unit tests in place then, every time you change something, you have your unit test to rely on. It not only saves your time to verify the output, but it also assures you that nothing is broken.

char and its relatives

In C, I was used to saying

char *psz = "This is some string";

here's what changes in VC++ :

VC++ has the ability to use multibyte characters and Unicode characters - this can be set using IDE options.

Between multibyte character system (MBCS) and Unicode, Unicode has greater acceptance, so we usually program in Unicode. Now to do that first all the string should be defined like this :

wschar_t *buff = L"This is some string";

here, the prefix L tells the compiler that the string is made up of Unicode chars and since char represents a 8 bit character, we need another datatype to represent Unicode char, so we have wschar_t (16 bit Unicode)

However, you might need to switch between ANSI string and unicode strings, to support such a situation, VC++ gives us  a macro TCHAR. It expands to wschar_t  if Unicode is defined else to char.

similarly, instead of harcoding "L" prefix, we again have an option in MFC to use a macro "_T"

We can write the macro ourselves in SDK as follows or include tchar.h

#ifdef UNICODE
#define _T(x) L##x
#else
#define _T(x) ##x
#endif

so now we can write

TCHAR *psz = _T("This is some string");

Modal vs Modeless Dialogs

Modal	Modeless
Application control is lost	is not lost
DialogBox API is used	CreateDialog API is used
EndDialog is used to destory it	DestroyWindow is used
Implements it own message loop	uses application's message loop
behaves like a synchronous call	behaves asynchronously

Calling conventions for functions

Finally I got to know what WINAPI is :)

it is a calling convention.

When a function call is made, you have a choice on how to pass function variables to the stack, they can be passed right to left or left to right, also there is a choice on whether the caller or the callee should clear the stack.

Based on these choices and some other things, we have different calling conventions :

__stdcall or CALLBACK or WINAPI,__cdecl,__fastcall,__thiscall

Check out the following links for details:

http://msdn.microsoft.com/en-us/library/984x0h58.aspx

http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx

http://www.cs.cornell.edu/courses/cs412/2001sp/resources/microsoft-calling-conventions.html

Cross Thread operations

For quiet some time now I have been using random ways to doing begin invoke. Here is a good pattern for it.

   1: public partial class Form1 : Form

   2: {

   3:     public Form1()

   4:     {

   5:         InitializeComponent();

   6:     }

   7:  

   8:     private void Form1_Load(object sender, EventArgs e)

   9:     {

  10:         ControlsHelper.SafeGui(this, delegate()

  11:         {

  12:             textBox1.Text = "using ControlsHelper on UI thread"; // this succeeds

  13:         });

  14:         Thread t = new Thread(new ThreadStart(WorkOnNewThread));

  15:         t.Start();

  16:     }

  17:     private void WorkOnNewThread()

  18:     {

  19:         ControlsHelper.SafeGui(this, delegate()

  20:         {

  21:             textBox1.Text = "using ControlsHelper"; // this succeeds

  22:         });

  23:  

  24:         textBox1.Text = "direct"; // this fails

  25:     }

  26: }

  27:  

  28: public static class ControlsHelper

  29: {

  30:     public static void SafeGui(Control control, MethodInvoker invoker)

  31:     {

  32:         if (null == invoker) return;

  33:         if (control != null)

  34:         {

  35:             if (control.InvokeRequired)

  36:                 control.BeginInvoke(invoker, null);

  37:             else

  38:                 invoker();

  39:         }

  40:         else

  41:             invoker();

  42:     }

  43: }

Language Recognition

A friend recently had to work with expressions, and he was looking around for some existing libraries which would let him do this. That's when he found ANTLR (http://www.antlr.org).

From the website :

ANTLR, ANother Tool for Language Recognition, is a language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions containing actions in a variety of target languages. ANTLR provides excellent support for tree construction, tree walking, translation, error recovery, and error reporting.

I tried to work with it ANTLR today and I think it is pretty good. One good thing about it is that it also has a GUI to write the grammar, once your grammar is ready, you can generate code in a number of languages.

My primary development language is C# so I was very happy to see that they have also explained how to tweak .csproj and compile the grammar in a visual studio project.

Lazy me

One whole week has gone by... and I have still not started "A pattern a week". I read a bit of  "Elements of Reusable Object-Oriented Software" and it has list of some simplest and most common patterns which one should start of with. They are :

Abstract Factory

Adapter

Composite

Decorator

Factory Method

Observer

Strategy

Template Method

So for this week it is Abstract Factory.