LINUX.ORG.RU

Qt Creator. Кто как предпочитает подключать *.ui ?


0

0

Агрегация через указатель:


// *.h:

#ifndef FORM_H
#define FORM_H

#include <QWidget>

namespace Ui {
    class Form;
}

class Form : public QWidget {
    Q_OBJECT
public:
    Form(QWidget *parent = 0);
    ~Form();

private:
    Ui::Form *ui;
};

#endif

// *.cpp:

#include "form.h"
#include "ui_form.h"

Form::Form(QWidget *parent) :
    QWidget(parent),
    ui(new Ui::Form)
{
    ui->setupUi(this);
}

Form::~Form()
{
    delete ui;
}

Агрегация:


// *.h:

#ifndef FORM_H
#define FORM_H

#include "ui_form.h"

class Form : public QWidget {
    Q_OBJECT
public:
    Form(QWidget *parent = 0);

private:
    Ui::Form ui;
};

#endif 

// *.cpp:

#include "form.h"

Form::Form(QWidget *parent) :
    QWidget(parent){
    ui.setupUi(this);
}


Множественное наследование:


// *.h:

#ifndef FORM_H
#define FORM_H

#include "ui_form.h"

class Form : public QWidget, private Ui::Form {
    Q_OBJECT
public:
    Form(QWidget *parent = 0);

};

#endif 

// *.cpp:

#include "form.h"

Form::Form(QWidget *parent) :
    QWidget(parent){
    setupUi(this);
}

Сабж. Как бэ намекают что в первом случае компилятер работает быстрее. Но третий куда более компактен.

★★★★★

Последнее исправление: Siado (всего исправлений: 1)

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

поэтому довольно странно использование динамической памяти просто так,
а не в случае крайней необходимости, когда например неизвестен объем реальной памяти.

Так что за 2 и 3, выбор между ними дело вкуса.

anonymous
()
Ответ на: комментарий от anonymous

когда например неизвестен объем реальной памяти


имеется ввиду объем реально требуемой памяти.

anonymous
()
Ответ на: комментарий от anonymous

>по-моему первый вариант не ахти

по дефолту через гуйню qt creator генерирует именно первый вариант. Либо тролльтехи чего-то не знают, либо наоборот, знают что-то хитрое. Ну и как третий вариант: им параллельно.

nu11 ★★★★★
()
Ответ на: комментарий от nu11

по дефолту через гуйню qt creator генерирует именно первый вариант. Либо тролльтехи >чего-то не знают, либо наоборот, знают что-то хитрое. Ну и как третий вариант: им >параллельно.


Я думаю что проблема в том что одни пишут, а другие используют.
Может из-за того, что trolltech купила nokia что-нибудь изменится.
Хотя на n900 довольно мощный процессор и много памяти.

Но скажем в случае с qt2 и его использовании на linux с 16 мегабайтами,
через некоторое время его использования система начинала тормозить.
Фишка была в том, что для каждого события она(qt) делала
new QEvent, вернее new наследник Qevenet и через некоторое время
память была очень сильно фрагментирована.

На обычной машие разработчика такого эффекта вряд ли добьешься.
Памяти там сильно больше и приложения на компьютере вряд ли сутками работают.

Это я к тому, что эффект конечно в общем-то незаметен от таких вещей,
если конечно не создаешь объекты очень часто, или очень много, или твое
приложение запускают на пару часов, а потом закрывают или не пытаешься запустить приложения на какой-нибудь embedded платформе.

anonymous
()

Я бы выбрал второй вариант: лишние танцы с указателями ни к чему, как и наследование, которое реально не используется. Но если у креатора есть свои навязчивые предпочтения на этот счёт, то лучше ему не мешать.

const86 ★★★★★
()

Раньше использовал множественное наследование. Но при переходе на QtCreator вполне удобным оказался первый вариант, т.к. при использовании шаблонов самому лень было править, да и в последствии код, имхо, более читабелен. Но это лишь субъективное мнение.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от anonymous

Интересно, надо будет больше почитать насчёт этого. Если всё действительно так, как вы пишите - вернусь на третий вариант.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Однозначно вариант 1, ибо pimpl рулит. А отрицательное влияние на скорость здесь ничтожное: это далеко не самое узкое место в системе

Gorthauer ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

>Но при переходе на QtCreator вполне удобным оказался первый вариант, т.к. при использовании шаблонов самому лень было править

В настройках QtCreator можно выбирать из этих трех вариантов, который генерировать автоматом в шаблонах.

В топике все эти варианты были сгенерены в креаторе автоматом.

Siado ★★★★★
() автор топика
Ответ на: комментарий от Gorthauer

> Однозначно вариант 1, ибо pimpl рулит.

Pimpl безусловно вещь хорошая и нужная, но проектирование каждого класса по этой идиоме не всегда имеет смысл. В Qt pimpl используется почти везде, но Qt - это библиотека, т.е. важно не менять по возможности ABI.

m0rph ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.