[Megoldva:] Qt4: Mikor kell delete?

Egy pointer felszabadítása soha nem kötelező, csak memória szemét keletkezik, meg bugos kód. Meg ajánlott. Hacsak nem tettek a Qt4-be GC-t akkor én mindenképp felszabadítanám.
Mivel a konstruktorban hoztad létre ezért úgy illik, hogy a destruktorban (is) legyen felszabadítva, de akárhol máshol a kódban megfelel, csak aztán ne használd ezeket az objektumokat.
Mivel az osztály a QObjecttől származik, ezért én a destructort még megfejelném egy virtual-al is.

Szerintem.

Ja és az a delete mc is kellene.

Ha így csinálod kell delete, de tudod úgy csinálni, hogy ne kelljen.

A konkrét esetben:

class MyClass : public QObject {
    Q_OBJECT
public:
    MyClass(const QString& inFilePath, const QString& outFilePath);
    void doIt();
private:
    QFile inFile;
    QFile outFile;
};

//-----------------------------------------------------------------------
// a cpp fájl:

#include "myclass.h"

MyClass::MyClass(const QString& inFilePath, const QString& outFilePath) 
  : QObject(),
    inFile(inFilePath),
    outFile(outFilePath)
{
}

void MyClass::doIt() {
  // csinál valamit.
}

void MyDialog::start() {
  QString inPath;
  QString outPath;

  // egyéb részek

  MyClass mc(inPath, outPath);
  mc.doIt();
}

Azaz minek new, ha jó neked a sima változó. Qt-ben ha nem Widget-ekről van szó, akkor nem kell a new-t erőltetni. (Sőt a fő widget a main-ben is lokális szokot lenni.) Jelen esetben semmi nem indokolja a new használatát (bár ez izlés kérdése is). Sőt ebben az esetben a QObject-ből való származás is felesleges.

Egyébként parent tekintetében két dologról van itt szó:
- QObject leszármazott osztályt a parent-je felszabadítja
- QWidgetnél szintén (hiszen QObject leszármazott), plusz a parent területén jelenik meg (ezért nincs parentje a főablaknak).

Azaz az előbbi kód new-kkal Qt stílusban:

class MyClass : public QObject {
    Q_OBJECT
public:
    MyClass(const QString& inFilePath, 
            const QString& outFilePath,
            QObject* parent=0);
    void doIt();
private:
    QFile* inFile;
    QFile* outFile;
};

//-----------------------------------------------------------------------
// a cpp fájl:

#include "myclass.h"

MyClass::MyClass(const QString& inFilePath, const QString& outFilePath,QObject* parent) 
  : QObject(parent),
    inFile( new QFile(nFilePath,this)),
    outFile( new QFile(outFilePath,this))
{
}

void MyClass::doIt() {
  // csinál valamit.
}

void MyDialog::start() {
  QString inPath;
  QString outPath;

  // egyéb részek

  MyClass mc(inPath, outPath);
  mc.doIt();
}

Mint látható a QObjectek amiknek felszabadítását a Qt-ra bízzuk, megkapják a parent-et a konstruktorban.
A MyClass-t továbbra is helyi változóként használom, mivel logikailag is az. :)
Persze működne ez is:

// Konstruktorban:
  MyClass mc=new MyClass(inPath, outPath,this);
// Valahol máshol
  mc->doIt();

Ez utóbbi most csak példa, a te esetedben lokális változó kell.

Összefoglalva:
A Qt mem kezelésében nincs semmi mágia. Ha egy QObject leszármazottnak megadod a parentet, akkor az bejelentekzik a parentnél, és a parent destruktora felszabadítja majd. Ha te valamiért előbb megszűnteted delete-tel, akkor a destruktorában megint szól a parentnek, hogy vegye ki a listából. Azaz tehát biztonságosra van megírva, más dolgod nincs, mint beállítani a parenteket becsülettel...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Az attól függ, hogy a QObject létrehozásakor volt-e megadva parent paraméter, és akkor ha töröld azt, a tied is törlődni fog. De pl. a QWidget() konstruktor szülő nélkül hozza létre az objektumot, így ekkor kell a delete.

Ha pl. így hozod létre a QFile-okat:

inFile  = new QFile(inFilePath, this);
outFile = new QFile(outFilePath, this)

Akkor már nem fog kelleni a törlés ~MyClass()-ban.

QObject explicit törlésére amúgy célszerűbb a QObject::deleteLater() metódusát használni, mert ha csak úgy kicsapod az objektumot egy delete-tel, akkor ha az event queue-ban van signal, amit még ez az objektum kapna, akkor abból csúnya segfault lesz.