Q_OBJECT

[Alexandr Az]

Как обернуть сабж в макрос

Скажем если сделать так
#define MYQT_DEBUG Q_OBJECT

class Test: public QObject
{
   MYQT_DEBUG
};

Получим болт при линковке, как будто макроса никакого нету...

Как вы понимаете, макрос в оригинале не такой простой

[lit-uriy]

а в конечном итоге чего добится хочешь?

может так поступить:

Код:

class Test: public QObject
{
#ifdef MY_DEBUG
   Q_OBJECT
#endif
};

[spirit]

Как обернуть сабж в макрос

Скажем если сделать так
#define MYQT_DEBUG Q_OBJECT

class Test: public QObject
{
   MYQT_DEBUG
};

Получим болт при линковке, как будто макроса никакого нету...

Как вы понимаете, макрос в оригинале не такой простой

имхо так не получется сделать как вы хотите, ибо moc требует явное указание имени макроса Q_OBJECT.
см.сырцы moc'a. http://www.bessrc.aps.anl.gov/software/qt4-x11-4.2.2-browser/d5/d3c/moc_8cpp-source.html

[pastor]

Как обернуть сабж в макрос

А зачем такой изврат? (просто интересно )

[Dodge]

пожалуй никак, ибо сабжовый макрос обрабатывается мок'ом а мок вызывается перед препроцессором

[Alexandr Az]

может так поступить:
class Test: public QObject
{
#ifdef MY_DEBUG
   Q_OBJECT
#endif
};

В том то и дело, что так оно чичас и есть

А зачем такой изврат? (просто интересно Smiley)

Дело в том, что мне нужны метаданные в дебаг версии. Скажем для дебаг версии есть тулуза, которая визуализирует классы
Помимо самого Q_OBJECT в макросы куча вещей нуно запихнуть, причем разных. А то такой зоопарк в коде получается....

пожалуй никак, ибо сабжовый макрос обрабатывается мок'ом а мок вызывается перед препроцессором

Позволю себе здесь не согласится, ибо тогда конструкция

Код:

#ifdef MY_DEBUG
   Q_OBJECT
#endif

не обрабатывалась бы, откуда мок узнал бы о состоянии MY_DEBUG?

[spirit]

а причем MY_DEBUG к moc? просто при такой конструцкии препроцессор просто закроет Q_OBJECT и сразу получаем ошибку в консоль типа "Error: Class declarations lacks Q_OBJECT macro."

[lit-uriy]

я так представляю процесс, положим, у нас есть три файла: file-1.ui, filename.cpp/h:
1) qmake проходит по файлам указанным в pro-файле, создает make-файл в котором уже указано для какого файла надо запускать MOC
2) работа UIC -> ui_file-1.h
4) работа компилятора (препроцессор, затем копиллер) -> filename.o
5) работа MOC -> moc_filename.cpp
6) работа компилятора (препроцессор, затем копиллер) -> moc_filename.o
7) работа линкера -> *.exe (*.dll ...)

покрайней мере я так вижу последовательность действий при компиляции в консоли

т.е. qmake получается ответственный за поиск спец макросов для MOC'а и создание соответствующих команд в make-файле. И ищет он, видимо, только Q_OBJECT стоящий в начале строки, а остальное игнорит.

[Alexandr Az]

т.е. qmake получается ответственный за поиск спец макросов для MOC'а и создание соответствующих команд в make-файле. И ищет он, видимо, только Q_OBJECT стоящий в начале строки, а остальное игнорит.

Разве так важно что делает qmake?
В варианте с #ifdef для дебаг и релиз версии создаются моки (если заюзать qmake, в майк файле будет прописано мокать и релиз версию). Только в последнем случае после моканья он будет пустой.
Когда сидишь под экспресом, а он, понятное дело, не KDevelop, плевал на qmake. Моканье файлов в експресе - всего лишь прописывание в соответствующие хедеры командрую строку моканья. Да и вообще, мокать можно все подряд, плохо от этого никому не будет, просто вопрос производительности.

Следовательно, qmake реагирует тупо на слово Q_OBJECT.
Но когда мы мокаем релиз версию, где этот Q_OBJECT заключен в #ifdef, получаем пустой moc_*.cpp. Вывод, сначало предроцессор, потом моканье хедера.
Но тогда почему низя запхнуть в макрос, не понятно.....

[spirit]

ребята вы смотрели сырцы moc'a? только он парсит клбчевые слова, а следовательно и Q_OBJECT, а qmake никаким боком не парсит мета инфу, на то moc и метаобъектный компилятор.

[lit-uriy]

2 Alexandr Az, ты не внимательно мой пост читал, см. п.4, а затем п.5, а затем п.6

2 spirit, еслиб qmake ничего не парсил, он бы в make-файл записал, что все надо MOC'ом обрабатывать, а в make-файле выборочно, только те, что с Q_OBJECT'ом

[spirit]

2lit-uriy но ошибку, то возвращает moc не qmake.
строка 663 в moc.cpp.
в общем я считаю, что мы отклонились от темы.

[ритт]

а как на счёт

Код:

class Test: public QObject
{
    Q_OBJECT
    MY_DEBUG
// snip
};

если макрос MY_DEBUG должен содержать (или не содержать) какие-то декларации, которые непосредственно к объекту отношения не имеют, зачем засовывать туда Q_OBJECT?
или я чего-то не так понял?

другой вопрос: "откуда мок узнал бы о состоянии MY_DEBUG?"
всего-то и нужно что указать в .про-файле DEFINE += MY_DEBUG только для прохода мока /* ну, или не только - зависит от задачи */

[SASA]

Assistant:

Here are the command-line options supported by the moc:
….
-D<macro>[=<def>] Define macro, with optional definition.

Так мок узнает (например из pro) о MY_DEBUG.
А для того, что бы файл успешно промокался нужно явно написать макрос Q_OBJECT.