Dwukolorowa wieża hanoi

Ok, już rozumiem, co tutaj się stało. Kod jest prawidłowy dla parzystych liczb, z nieparzystymi dzieją się już głupie rzeczy, więc nie do końca rozumiem, po co ten warunek dotyczący parzystości. Ale mniejsza, na pewno jest potrzebny, a ja to zauważę później. Nie zmienia to faktu, że algorytm jest zajebiście niewydajny. Dla n = 6 wyrzuca nam sekwencję 57 kroków, a dla n = 8 aż 247. W przypadku n = 6, kiedy wrzucimy odtwarzanie na to średniej szybkości, widać co jakiś czas, że dane przełożenie dało się zrobić lepiej. Najlepiej widać to pod sam koniec - czyli np. po 50 kroku. A dla geniuszy takich jak ja, którzy byli zbyt leniwi na wklejenie tego gdziekolwiek i przekształcenie w czytelniejszy dla siebie sposób (to znaczy chociażby taki, żeby zawartość pliku wkleić od razu do programu sprawdzającego):

#include <iostream>
#include <fstream>
using namespace std;

void hanoi(int n, int A, int B, int C)
{
  if (n > 0)
  {
    fstream plik;
    plik.open("wyniki.txt", ios::out | ios::app);

    hanoi(n-1, A, C, B);
    plik << A << " " << C << endl;
    hanoi(n-1, B, A, C);
    plik.close();


  }
}

int main()
{
    int n;
    fstream plik;
    plik.open("wyniki.txt", ios::out | ios::app);

    cin >> n;
    plik << n << endl;
    plik << 3 << endl;


    while (n > 1)
    {
        if (n % 2 == 0)
            hanoi(n - 1, 1, 3, 2);
        else
            hanoi(n - 1, 2, 3, 1);
        --n;
    }


    return 0;
    plik.close();
}

Bez poprzednich wpisów nie doszłabym do tego, jak ten zwykły algorytm z wież hanoi przekształcić, więc jestem Wam ogromnie wdzięczna za wkład. Spróbuję popracować nad wydajnością, bo póki co jest to kluczowy problem.

Niby nie, ale zawsze lepiej się czuję, jak algorytm działa wydajnie... takie zboczenie raczkującego informatyka.