LINUX.ORG.RU

Почему не срабатывает static_cast в main.cpp, а в других местах срабатывает?

 , ,


0

5

Я в проекте использую расширенный от QGuiApplication класс, названный мною App, который отличается от QGuiApplication только одним дополнительным элементом:

class App : public QGuiApplication
{
public:
    App(int &argc, char **argv);

    Core core;
};

И у меня есть такой макрос:
#define APPCORE static_cast<App*>(qApp)->core

Он мне нужен для того, чтобы обращаться к ядру из любого места программы. И его использование нормально компилируется во всей программе. В любом классе, будь он наследником QObject, или обычный класс, данный макрос нормально компилируется.

Однако, если я пытаюсь использовать макрос APPCORE в функции, которая просто лежит в main.cpp:
void criticalError(QString message)
{
 ...
    APPCORE.emitCriticalError(message);
 ...
}

то при компиляции возникает ошибка:
../src/main.cpp: In function ‘void criticalError(QString)’:
../src/main.h:21:39: error: invalid static_cast from type ‘QApplication*’ to type ‘App*’
 #define APPCORE static_cast<App*>(qApp)->core
                                       ^
../src/main.cpp:78:5: note: in expansion of macro ‘APPCORE’
     APPCORE.emitCriticalError(message);
     ^
Makefile:1998: recipe for target 'main.o' failed
make: *** [main.o] Error 1

Что-то я не пойму, почему приведение типов from ‘QApplication*’ to ‘App*’ работает во всей программе, но не работает именно в этом месте?

UPD Ссылка на минимальный пример: Почему не срабатывает static_cast в main.cpp, а в других местах срабатывает? (комментарий)

или : https://www.dropbox.com/s/6y53llhtcw38fh1/staticCastSample.rar?dl=0

★★★★★

Последнее исправление: Xintrea (всего исправлений: 4)
Ответ на: комментарий от anonymous

А потом во второй, третий и т. д.? Тащить всё через параметры или внутреннее состояние через много уровней - это ж тоже херня получиться?

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

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

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от Deleted

Смотрите, как мы изподвыподвертанулись и избавились от синглтона!

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от Deleted

Да именно так, писать больше, но улучшается читаемость и тестируемость такого кода. Это важнее.

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

Модульностью.

Синглтон сам по себе не является антипаттерном, проблема в его избыточном использовании всякими индусами. Конкретного ответа не будет, потому что в каждом кейсе будет своё решение, нужно смотреть на код.

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

Модульностью

Тоже слишком общно.

Синглтон сам по себе не является антипаттерном, проблема в его избыточном использовании всякими индусами. Конкретного ответа не будет, потому что в каждом кейсе будет своё решение, нужно смотреть на код

Да, я это знаю. Просто видел во многих местах, как некто рассказывает на тему антипаттерна, а причины загуглить не смог

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

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

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