Вызов деструктора в конструкторе

Забабахай статический метод, будь мужиком.

Эээ.. Сделать статическим деструктор или все остальные методы? Просто в конструкторе вызывается ряд методов, которые готовят данные. На любом из этапов может быть вызван exit(0) (ну или исключение, сейчас кидается фуллстоп для простоты). Если все «подготовительные этапы» прошли успешно, выполняется действие и объект должен самоуничтожиться.

Воспользуйся функцией вместо объекта.

Если время жизни экземпляра не превышает время жизни его конструктора, задумайся над персмотром архитектуры. Если суть методов объекта сводится к выполнению какой-то работы один раз при конструировании, сделай их статическими и вызывай из конструктора (хотя это, опять жеЮ ниочинь подход, но я видел такие случаи - клас - просто обертка для набора функций). Тебе же объект не нужен по сути.

В комплекте идут хэш-данные, списки и рекурсивное создание таких же объектов внутри него. Так что просто функцией тут не обойтись.

Если нужен доступ к внутренностям этого класса, то эту функцию можно зафрендить с этим классом.

Хорошо. О пересмотре архитертуры. Вот сейчас оно примерно так:

// xxx.h
#include ...

class Xxx : public QObject
{
  Q_OBJECT

public:
  Xxx(QString FileName);

private:
  Xxx * child;

  void func1(QString FileName);
  void func2 ...
  ...
  ... func5;

  ... run ...
  ... recursiveLoad(QString FileName);
}

// xxx.h
#include ...

Xxx::Xxx(QString FileName)
{
   Func1(...); // May be killed here
   Func2 ...   // Or here
   ...         // Or even here
   Func5       // But the most probably here
   run(void);
}

Xxx::run(void)
{
  // cycle for commands
  // and if we've find the command we didn't load yet - load it:
  child = new Xxx("Path/To/Command/File/And/Its/File/Name.xxx");
  // May be recursive for more than N levels.
}

Ты не показал не одной причины использовать объект вместо функции.

То, что для его работы потребуется

private:
    QList<Command>  * commands;

На стеке этот список определи в рекурсивной функции. Еще причины есть?

1) Стек не лопнет, если я её рекурсивно overдофига раз вызову?
2) В C++ НЕТ вложенных функций (это костыль), поэтому одиночную функцию придется сопровождать еще добрым десятком того, что сейчас в private.

Стек не лопнет, потому что данные все равно будут в куче. Функции положи в файл реализации и сделай их static.

А суровые бородатые дяди в свитерах не будут тыкать меня вилами с надписью ООП за такую реализацию?

Нет. :)

Но если кто-то откроет рот, то сразу засунь их в какой нибудь namespace. :)

Сделать статическим деструктор

обьясните мне плз что здесь имеется в виду?

Никогда не выполняй тяжёлых вычислений, не относящихся к созданию объекта, в его конструкторе. _Никогда_.

Amp предложил самый удобный вариант. Если нужно в нескольких местах вызывать, сделать статическую функцию:

class Xxx {
   Xxx();
   void func1();
   void func2();
   void func3();
   ...
   static void compute()
   {
       Xxx xxx;
       xxx.func1();
       xxx.func2();
       xxx.func3();
       xxx.run();
   }
};

И вызывай: Xxx::compute();

Соптимизируется, лол.

С чего бы?

Неиспользуемое значение.

Но есть побочные эффекты, в инструкции i++ значение тоже не используется.

Да, действительно, сейчас проверил - не оптимизируется.

Попутал с фактом, что такой объект тут же уничтожается, ибо не используется.

В таком виде он ругается на undefined reference to 'Xxx::compute()'. Вызов из другого модуля, хидер подключен.

куда катится этот мир ...

печитай ООП для С++ юный падаван.

PS я кстати натаскиваю падаванов Qt4 С++, если есть желание то черкни письмецо, адрес есть в профиле.

Компоновщик не находит функции. Добавь в makefile правило сборки этого объектного файла.

А что, все записанное в .pro qt теперь игнорирует?

И это правильный вариант.

Пардон, не заметил. Тогда добавь в .pro.

Пересобери проект для уверенности.