Как разместить код Qt-класса в main.cpp?

[d13mon]

День добрый,

Давно интересует один вопрос. Создаем простейший проект (использую MSVC2010) Qt Application - там класс производный от QWidget (в 2-х файлах - .h и .cpp) и main.cpp. Компилируем, собираем, всё ок. Затем пихаем весь код в main.cpp:

Код:

#include <QtGui/QWidget>
#include <QtGui/QApplication>

class TestWidget : public QWidget
{
	Q_OBJECT

public:
	TestWidget(QWidget *parent = 0, Qt::WFlags flags = 0)
		: QWidget(parent, flags)
	{
	}
	~TestWidget(){}	
};

int main(int argc, char *argv[])
{
	QApplication a(argc, argv);
	TestWidget w;
	w.show();
	return a.exec();
}

и линковщик выдает странные ошибки, характерные для случаев, когда с  Q_OBJECT что-то не так.

Код:

main.obj : error LNK2001: unresolved external symbol "public: virtual struct QMetaObject const * __thiscall TestWidget::metaObject(void)const " (?metaObject@TestWidget@@UBEPBUQMetaObject@@XZ)
1>main.obj : error LNK2001: unresolved external symbol "public: virtual void * __thiscall TestWidget::qt_metacast(char const *)" (?qt_metacast@TestWidget@@UAEPAXPBD@Z)
1>main.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall TestWidget::qt_metacall(enum QMetaObject::Call,int,void * *)" (?qt_metacall@TestWidget@@UAEHW4Call@QMetaObject@@HPAPAX@Z)

Кто-нибудь знает, из-за чего это и как побороть?

[Пантер]

#include "main_moc.cpp" в самом низу main.cpp сделай.

[GreatSnake]

прогони main.cpp через moc:

Код

DOS
moc -o moc_main.cpp main.cpp

Полученный moc_main.cpp в ставь в самом конце main.cpp через

Код

C++ (Qt)
#include "moc_main.cpp"

[d13mon]

#include "main_moc.cpp" в самом низу main.cpp сделай.

О,спасибо

Правда, помогло не #include "main_moc.cpp", а #include "main.moc"

[d13mon]

прогони main.cpp через moc:

Код

DOS
moc -o moc_main.cpp main.cpp

Полученный moc_main.cpp в ставь в самом конце main.cpp через

Код

C++ (Qt)
#include "moc_main.cpp"

Попробовал так тоже, пишет

Код

DOS
D:\WORK\PROJECTS\CPlusPlus\QT\Qt_training\TestWidget>moc -o moc_main.cpp main.cpp
main.cpp(0): Note: No relevant classes found. No output generated.

На выходе получаю пустой moc_main.cpp

[Alex Custov]

прогони main.cpp через moc:

если просто добавить #include "main.moc", то qmake сам определит, что нужно сгенерить main.moc и создаст правила.

[schmidt]

Затем пихаем весь код в main.cpp.

У меня только один к вам вопрос: зачем?

[VozaMFC]

Затем пихаем весь код в main.cpp.

У меня только один к вам вопрос: зачем?

Что бы в одном файле все было.

[Bepec]

И получаем дикую головную боль при использовании другой IDE  

PS к примеру тот же VS 

[twp]

А какие проблемы при использовании в VS такого подхода?

[Bepec]

VS создаёт моки и прочее в процессе компиляции кода. Причём местонахождение папки для генерируемых файлов меняется в настройках проекта. Т.е. мне например удобно, что они сразу улетают в темп и не мучают меня своим присутствием в папке с исходниками.

А раз их местонахождение может измениться за 5 секунд, значит чтобы их найти, необходимо прописывать абсолютные пути для их подключения.

Проще выражаясь - создаётся фиг пойми где, а даже если и пойми где, нужен абсолютный путь.

PS кто-то скажет - так тебе и надо, а я скажу - нафиг мне файл, который каждый раз заново создаётся, в папке с проектом.

[schmidt]

Что бы в одном файле все было.

  5 баллов!

Запихнув все классы проекта в один файл вы не получите ничего, кроме головной боли. С таким подходом у вас получится не то что винегрет вместо проекта, а каша из 10 круп. Как только число ваших классов приблизится к десятку, а код каждого класса перестанет умещаться в окне редактора, вы проклянёте себя самыми последними словами после 1-2х дней работы с этой высокохудожественной свалкой

[xokc]

Запихнув все классы проекта в один файл вы не получите ничего, кроме головной боли. Как только число ваших классов приблизится к десятку вы проклянёте себя самыми последними словами после 1-2х дней работы с этой высокохудожественной свалкой

Как легко вешать ярлыки. А может у него НИКОГДА в этом проекте не будет десятка классов? Будьте менее категоричны.

[GreatSnake]

Не понимаю "непониманий" schmidt и Bepec.
Для серьёзных проектов, конечно, сей случай навряд ли подойдёт.
Но для test-case-ов и для обкатки какого-нибудь случая считаю такой подход самым оптимальным.
Сам здесь уже не первый год пользуюсь им для рабочих примеров.

[Bepec]

Выражу мысль так.

Для использующий креатор - это, без сомнения, удобное решение для тестовых проектиков.

Для тех, кто НЕ использует креатор - это решение будет удобно лишь после настройки IDE и, возможно, шаманства с путями.

Для тех, кто соберётся передавать проект кому-то - это создание проблем.