Inorder, Preorder, and Postorder traversal of a binary tree in C++
I can see a few changes that at least might be worth considering.

Minimize Requirements

All else being equal, you typically want to minimize the requirements you place on the type contained in a container like this. For example, where you need to do comparisons, you can use the same operator (typically &lt;) to do all the comparisons. For example, in your Find, we can do just a little rearranging to get this:

template&lt;typename T&gt;
T BTree&lt;T&gt;::Find(T key)
{
    Node&lt;T&gt;* current = this-&gt;root;

    while (current!= nullptr)
    {
        if (current-&gt;data &lt; key)
            current = current-&gt;right;
        else if (key &lt; current-&gt;data)
            current = current-&gt;left;
        else // Neither is less than the other, so they must be equal
            return current-&gt;data;
    }
}


With this, T only needs to define "less than" for our code to work (where it previously required &lt;, &gt; and ==).

Check recursion

Your PrintInOrder looks broken:

template&lt;typename T&gt;
void BTree&lt;T&gt;::PrintInorder(Node&lt;T&gt;* ptr)
{
    PrintPreOrder(ptr-&gt;left);
    cout&lt;&lt;ptr-&gt;data&lt;&lt;endl;
    PrintPreOrder(ptr-&gt;right);
}


This seems to do a pre-order traversal of the left sub-tree, prints the current, then a pre-order traversal of the right sub-tree. For in-order, you want an in-order traversal of the left-subtree, process the current node, then in-order traversal of the right subtree. With only a few nodes (so the tree is never very deep) this probably may not be visible, but it's clearly wrong.

The same applies to your PrintPostOrder.

Simplify where possible

At least to me, your PrintPreOrder seems unnecessarily complex. I'd do something like:

template &lt;class T&gt;
void PrintPreOrder(Node&lt;T&gt; *ptr) { 
    if (ptr == nullptr)
        return;

    std::cout &lt;&lt; ptr-&gt;data &lt;&lt; "\n";
    PrintPreOrder(ptr-&gt;left);
    PrintPreOrder(ptr-&gt;right);
}


With this we only do one check for a null pointer in one place.

Likewise, your Add currently looks like this:

template&lt;typename T&gt;
void BTree&lt;T&gt;:: Add(T val)
{
    if (root==nullptr)
    {
        root = Add(val, nullptr);
    }
    else
    {
        root = Add(val,root);
    }
}


This checks whether root is a null pointer, and if it is it explicitly passes a null pointer. Otherwise, it pass root. If we just pass root, (whether it's a null pointer or not) we get exactly the same effect.

template&lt;typename T&gt;
void BTree&lt;T&gt;:: Add(T val)
{
    Add(val, root);
}


Avoid std::endl

When people use std::endl, they typically just want to write a new-line to a stream. Unfortunately, that's not quite all that std::endl actually does--in addition to writing the new-line, it flushes the stream. Flushing the stream unnecessarily can lead to a dramatic speed loss (e.g., 10x is pretty common).

On the rare occasion that you actually do want to both write a new-line and flush the stream, I think it's better to do that explicitly:

std::cout &lt;&lt; "\n" &lt;&lt; std::flush;


At least in my experience, actual uses for this are fairly rare though.

Prefer enum's to magic numbers

Your Print currently sorts out the order for the printing like this:

if (o==1)       // ...
else if (o==2) // ...
else if(o==3)  // ...


Rather than 1, 2 and 3, I'd rather use an enumeration:

enum order { PRE_ORDER, IN_ORDER, POST_ORDER };


Then Print would look something like this:

template&lt;typename T&gt;
void BTree&lt;T&gt;::Print(order o)
{
    switch (o) { 
        case PRE_ORDER:  PrintPreOrder(root);    break;
        case IN_ORDER:   PrintInOrder(root);     break;
        case POST_ORDER: PrintPostOrder(root);   break;
    }
}


At least to me, this seems considerably clearer and more readable (also note the use of a switch statement to directly express the intent of choosing one of multiple alternatives).

Don't Repeat Yourself

Right now, you have code in both Add and Find to find a node (if any) with a particular value. Oddly, the two use entirely different approaches to this problem. Rather than having two copies of code to find a node based on a key, I'd rather have one piece of code that's used from both:

Node *&amp;find_key(T key) { 
    Node *current = root;

    for (Node *current = root; current != nullptr;) {
        if (key &lt; current-&gt;data)
            current = current-&gt;left;
        else if (current-&gt;data &lt; key)
            current = current-&gt;right;
        else
           break;
    }
    return current;
}


With this, we can rewrite Find to look something like:

T Find(T key) { 
    Node *pos = find_key(key);
    if (pos != nullptr)
        return pos-&gt;data;
}


Likewise, Add would look something like this:

void Add(T key) { 
    Node *&amp;pos = find_key(key);
    if (pos == nullptr)
        pos = new Node(key);
}


Avoid Undefined Behavior

As currently defined, if you call Find for a key that isn't present in the tree, execution flows off the end of the function without returning a value, leading to undefined behavior. There are various ways to deal with this, such as a Maybe or Optional type that carries both the return value itself and an indication whether a value is actually present. Another possibility (probably not as nice, but at least it does work) is to use an approach about like the find_key shown above, returning a null pointer if a value isn't present.