Как определить, запущен ли основной цикл QApplication::exec() или еще нет?

Итить.. Мой либастрал сегодня в порядке чуял я в соседнем треде ))

Да просто:

guiEventLoopIsRunning = true;
app.exec();

Ну как оно у тебя там наследуется, вот и оберни экзек родителя в свой и там устанавливай этот буль.

В доке есть такое:

bool QCoreApplication::startingUp()

Returns true if an application object has not been created yet; otherwise returns false.

Создание и запуск основного цикла - это вроде как разные вещи, разве нет?

Лол я знаю, но не скажу :-)

Ну как оно у тебя там наследуется, вот и оберни экзек родителя в свой и там устанавливай этот буль.

Ну я так и сделал. Но в свете того, что использовать наследника QApplication с дополнительными полями вместо кучки синглтонов - это моветон, то хотелось бы узнать как сделать без переопределения метода exec().

Из кода видно, что тебя интересует QCoreApplicationPrivate::in_exec, но он нигде не выдаётся наружу (и, походу, используется только для ручного дебага).

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

app.setproperty("started", true);
app.exec().

Не соглашусь. Тут уже вопрос интрефейса. Так будет топорная и понятная обертка геттер, а в твоем случае непонятные js-style сеттеры, геттеры. Можно и их использовать, но их же следует обернуть в «топорные» методы в угоду понятности и однозначности.

Схренали моветон?

Но это так — первая реакция. На деле же, я хз что у тебя там за архитектура и почему тебе стало удобнее в кучу синглтонов. У меня у самого тут в работе «раскоряка» такая, что без слёз не взглянешь. Но в твоем случае, насколько я вижу сейчас, приватный буль и геттер статуса выглядит вполне кавайно.

Отслеживай сигнал started() у основного потока (QApplication::thread()))

Щщи, возможно как вариант. Но снова это в итоге просто обертка над неким булевым статусом «аглы» или «не аглы».

Два извечных русских вопроса как и назачем.

Зато ничего создавать не надо. Но вообще ТС не написал, зачем ему это надо, может, другие решения подойдут лучше

А specified ли behavior у соединения сигналов и слотов, до создания очереди в которой они разгребаются?

Хотя, будь я автором QCoreApplication таки создавал бы очередь при создании объекта.

В общем случае определить нельзя. Это как курит ли человек после того как потушил сигарету? Вроде бы как уже и нет, но вообще да. exec() это один из способов обработать накопившиеся события, он может быть запущен один раз, несколько, а может и не быть запущен вовсе. В каждый конкретный момент в главном потоке нельзя понять как и когда твоё событие будет обработано в следующий раз. Это не RAII-объект со своим циклом жизни. Более того, циклы могут быть вложенными и даже создаваться временно, как, например, делает QDialog, запущенный до QApplication::exec(). Другими словами, нужно понять конкретную задачу и решить её вручную, к примеру, взводом какого-нибудь флага, который будет иметь своё целевое назначение, а не абстрактное запущен ли главный цикл.

Связи сигнал-слот легко объявляются/добавляются и «запоминаются» еще до начала ивент-лупа. Но, если объявленный сигнал заэмитить до начала лупа, то луп его не увидит.

Даже если queued connection используется?

Да. Ибо сигнал должен куда-то отложиться (в очередь, которая создается только при старте лупа).

до создания очереди в которой они разгребаются?

При прямом соединении посылка сигнала почти что эквивалентна обычному коллбэку, поэтому очередь не нужна

А точно очередь создаётся при создании цикла(читай при вызове exec)?

Непонятно зачем так делать, кроме как добиться потери поставленных в очередь сигналов.

Ну так запилили авторы, что теперь, не писать на культях чтоли? ))

использовать наследника QApplication с дополнительными полями вместо кучки синглтонов - это моветон

Все как раз с точностью до наоборот.

Обоснуй.