Как раз в общем случае верно, объект QThread будет принадлежать создающей его нитке, а не порождаемой им.
Так это называется "по умолчанию" и к общности отношения не имеет.
Тут не знаю про что вы говорите.
Просто когда дело дойдет до события DeferredDelete (порожденного deleteLater), то объект удалится невзирая на "незавершенный поток".
Это вы ваши сложности с deleteLater и вообще с очередями сообщений, пытаетесь представить вселенской опасностью. А она яйца выеденного не стоит, если понимать, что делаешь.А по другому, лучше ничего не делать.
Никогда не боялся очередей. Да, получал неск раз по ушам, но гораздо меньше чем в др местах. Вернемся к первоисточнику
C++ (Qt)
if(thread != NULL){
thread->startThread = false
thread->quit();
thread->wait();
thread->deleteLater();
Вы совершенно правильно указали что без контекста невозможно предсказать поведение deleteLater. Весьма вероятно где-то выше понадобится
C++ (Qt)
thread->moveToThread(thread)
Иначе какой смысл крутить там EventLoop? Но тогда событие DeferredDelete будет помещено в очередь thread - но она уже остановлена (thread->quit()). Когда же удалится thread? Наверное никогда (без доп действий). Почему "наверное" - ну хз, может у Qt есть доп процессинг для этого случая (вряд ли, но не проверял).
Спрашивается: а за каким <template> было так делать, искать ненужных приключений? Чем было плохо простецкое delete? Зачем надо было продлевать жизнь thread? Что хотели еще от нее получить? Это называется "понимать что делаешь"? Совсем наоборот. Тоже мне, сокол защищающий выеденные яйца
