Iterator for traversing a tree
Clean up allocated memory (everything newed should be deleted), or use smart pointers to do it for you. (Perhaps each tree node should own its children, and store them in unique_ptrs, and the parent should be a raw pointer).
There doesn't seem to be any benefit to overloading operator new for the Tree class.
Currently, the iterator is more of a sub-tree iterator, as it never returns to the parent. e.g. for a tree with edges: A->B->C and A->D if you start iterating at B, you will only iterate from B to C, and never reach D.
Iterators are normally defined outside of the corresponding container class. We can use an iterator typedef in the container to refer to the iterator class.
operator* should return a reference, not a pointer (operator-&gt; should return a pointer).
We have !=, but no ==.
We have a pre-increment operator++, but not post-increment operator++.
It would probably be best to write unit tests for things that are expected to work, e.g.: *i (returns a modifiable reference), *i++ (returns a modifiable reference and then increments i to point at the next value), etc. This can be tedious, but is really the only way to ensure correctness.
The full requirements for a forward iterator are listed here (and in the linked pages), and many of them could be translated into tests cases. This iterator should arguably be a bidirectional iterator.
Standard containers also supply a const_iterator version (and reverse iterators, though that's usually simple to add).


To be honest, I'd suggest starting with something a bit simpler like an array class, and corresponding iterators.



Note that we can traverse a tree in many different ways (depth-first in-order, depth-first pre-order, depth-first post-order, breadth-first). For a full-featured implementation of this sort of thing, see the ASL Forest class.

Since we're iterating nodes, not values, we don't have to worry about "order", but we should still call the class something like tree_depth_first_iterator, to distinguish it from the alternative(s).