Comments by Mattias Högström (Top 14 by date)

The 3 lines looks almost the same.
What changes is the towers you move between.

You have to run it step by step in you head or use pen and pencil.
Do you know how to traverse a binary tree in order to visit all nodes?
Instead of a binary tree, it is a tree which splits in three.

The program completely finishes all left branches first.
From the beginning all rings are on the first tower.
We enter Hanoi(1,2,3,3)
Then we enter the recursed Hanoi(1,3,2, 3-1)
Then we enter the recursed version of Hanoi(1,2,3 2-1) again.
Then he print "Move from Tower #1 to Tower #3", because n == 1
#1 and #3 are tower 1 and tower 3, the first time.
This happens at depth 2.
Then it returns to depth 1, and there it has to continue with the middle and right branch.

What he is doing, is doing a composed move, which requires three sub moves.
On the second call he takes into account that the rings have moved in the first call.
(He moves around the position of the tower). Then he continues to move the rings.

Recursion is usually not this hard.
This kind of solution is not something you just invent by accident.
You usually make the solution or part of it (the tree with the moves) on a paper.
Then generalise and abstract an algorithm.

What the author probably realised was that he could abstract it into three identical sub trees.
Then he found a clever way to traverse the tree from left to right using recursion.

Understanding the code without imagining the call tree is close to impossible.

Thanks :)

Here is a link to someone that has experienced a lot of problems getting the debugview to work.
http://geekswithblogs.net/cyoung/archive/2007/09/16/115390.aspx
It seems to relate to the support of multiple remote desktop sessions on newer OS:es.

You are right.
Hey!! Don't call it my macro. I just tried to correct it (but missed making it foolproof).
I hate macros. They are error prone and makes it harder to debug the code.
I would prefer an inlined function over a macro.

std::swap is the preferred alternative

ps. According to my coding style guideline
Even 1 line if else statements should use braces. :)

True. Something like this

int myArray[10];
generate(myArray, &myArray[sizeof(myArray)/sizeof(myArray[0])], rand);

For readability, I prefer using normal for-loops.
Easier to debug too.

The code didn't become clearer.

Theoretically, the assignment looks ok now,
but your code contains a couple of errors and omissions.
I don't think it compiles, so I am not sure what the error is.

1.
Allocate myClass object or use an object.
myClass* b = new myClass();
myClass b;

2.
When using subclasses and virtual methods, a pointer must be used.
Base me;
me=NewClass();
=== Change to ===>
Base *me = newClass();

3.
Exposing a public variable is bad practise, and of pointer type, is worse.
If you really need to pass around pointers, use the constructor and/or get set methods.
The reference type (myClass& par) is even better than pointers because it can't be null.
A "smart pointer" is even better to use than raw pointers.
http://en.wikipedia.org/wiki/Smart_pointer

Your code is not easy to read.
Days like this I really appreciate F#.

You have a buffer overrun or underrun. you pointer arithmetic is wrong.
The sequence FDFD tells me that.
In debug mode, allocated memory is surrounded by markers, guard bytes, magic numbers.

From http://en.wikipedia.org/wiki/Magic_number_(programming)
FDFDFDFD Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory

Either variable i or j is out of bounds.
Hover over them and find out their values when the debugger throws the exception
Then go back in the callstack and find out why they are wrong

The F# language is a managed language.
You must call it from managed or mixed code (or call it from COM)

Solution 1, suggested by Cdrake.
1. Convert your C++ app to C++/CLI (/clr switch)

Another option is:
2. Create an interop assembly/DLL in C++/CLI which you use as a normal DLL from your C++

Oh... I was distracted by the creation/assignment of the field.

I personally think derived getters and setters are ok,
but I would never expose the variable _field to a derived class.
Since you set the _field in the constructor I would make it private.
public ICompositeDataType Field { get; private set;}

If it is needed to change the reference at runtime, I would make the Field set accessor protected.
public ICompositeDataType Field { get; protected set; }

In this particular case, I think it is ok.
Of course, if you need 5-10 protected fields, it is probably an indicator of bad design.