Russian Qt Forum

Во вложении, очень маленький тестовый проект проект.
Его компиляция в Kubuntu 14.04 х86_64 (а так же в еще одном другом линуксе) и последующий запуск приводит к краху приложения (SIGSEGV), причем где-то в недрах Qt.

Под виндой не пробовал. Если кто сможет, отпишитесь.
Если у кого-то этот проект работает, тоже отпишитесь.

Собственно вопрос задачи, что не так с проектом?
Там один интерфейс, одна реализация и использование этого добра.
Все предельно очевидно. Но не работает.

Qt 4.8.*, mingw 4.6.2, Windows XP

Ну так порядок инициализации статических объектов не определен. :)

Перенесите это:

C++ (Qt)
IApplication::IAppMap IApplication::_impl;

перед этим:

C++ (Qt)
BaseApplication BaseApplication::_application;

А вообще, лучше так не мудрить.

C++ (Qt)
IApplication::IAppMap IApplication::_impl;

C++ (Qt)
BaseApplication BaseApplication::_application;

Вот у gil9red mingw почему-то смог определить порядок инициализации, приложение работает.

Просто перенесите ее в другой файл и тогда map сконструируется раньше.

Вот как раз это.

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

Сделайте так и у вас все заработает:

C++ (Qt)
#include "baseapplication.h"
 
#include <QtCore/QCoreApplication>
#include <QtCore/QDebug>
 
using namespace core;
 
IApplication::IAppMap IApplication::_impl;
BaseApplication BaseApplication::_application;
QCoreApplication * BaseApplication::qtapp = 0;
 
BaseApplication::BaseApplication()
    :IApplication()
{
    registerImplementation("BaseApplication", this);
}
 
int BaseApplication::run()
{
    if(qtapp)
        return 0;
    else
        return 1;
}
 
void BaseApplication::onInitialized()
{
    qDebug() << QObject::tr("BaseApplication initialized");
}
 

Вот поэтому так, как сделали вы, делать не надо.
И тогда не понадобиться использовать такие костыли.

А что делать, когда появится еще один наследник?
class AdvancedApplication : public IApplication например.

В общем, "Диктую ответ на 1 -й вопрос 9-го билета."  ;D

Действительно проблема в порядке инициализации статических объектов.

Варианты решений:

• В файле проекта в секции SOURCES нужно перенести iapplication.cpp над baseapplication.cpp
  Это влияет на порядок инициализации и приложение будет работать.
• Задать высокий приоритет для статического объекта _impl класса IApplication
  Таким образом IApplication::IAppMap IApplication::_impl __attribute__ ((init_priority(101)));
  Но это решение не кроссплатформенное кажется.

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

А почему компилятор сам не может увидеть зависимость одного объекта от другого?
С отдельным файлом, некрасиво как-то :/

А как бы сделать аналогичную структуру без статических объектов?

Компилятор компилирует единицу трансляции (один файл), про другие он даже не догадывается.

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

А так, почитайте Александреску про синглетоны, он подобные случаи неплохо разбирает.

Спасибо за полезные ответы.