Можно ли ждать завершения потока в деструкторе класса?

[The Nameless One]

Корректным ли это будет?

Код:

Application::~Application()
{
      WaitForSingleObject(hThread,  INFINITE);
      CloseHandle(hThread);
}

int WINAPI WinMain(...)
{
    Application a;
    a.run();        //будет запущен поток
    return 0;
}

[Dimka]

The Nameless One, по-моему это вообще дико.

Где выделяешь память - там и освобождаешь.
Где открываешь файл - там и закрываешь.
Где делаешь fork - там же и делаешь join.

Если ты запустил поток внутри run, то и жди внутри run - все вопросы отпадут сами собой.

[Ochkarik]

Dimka, мне честно говоря тоже так показалось...
а потом я подумал - это же новая нить?
допустим я ее запустил - она работает, и мне надо какие то другие действия делать, не связанные с классом Application. Например еще десять нитей запустить.
тогда получается либо надо процедуру ожидания в открытые члены класса выводить, либо так.
более того, у такого, дикого с первого взгляда, подхода есть плюсы:
1. если размещение статическое, то winmain(абстрагируясь от того что это winmain) никогда не выйдет пока не дождется завершения нити.
а вот если динамическое - то... тогда непонятно.
впрочем я не агитирую. моя первая мысль тоже была о том что это дикость)

[Антон (LogRus)]

Это вполне нормально, если поток создаётся методами класса и объект хранящий поток это класс, то при разрешении он обязан вернуть всё как было. Главное делать не просто join, а проверять перед этим запускался или поток и не сдох ли он.

ИМХО, не вижу в этом ничего страшного.

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

[The Nameless One]

Спасибо!

[Dimka]

Что так можно написать - никто и не спорит. Можно и ногами уши чесать - тоже при должной ловкости не проблема.

И всё это не отменяет того факта, что интерфейс класса Application получается диким. А в языках со сборщиком мусора это вообще имеет риск привести либо к утечке памяти, либо к параличу сборщика.

Мне даже слегка понятна ситуация, когда деструктор принудительно завершает работу потока. Но совершенно непонятна ситуация, когда он ждёт и, быть может, зависает.

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

Ещё раз: если в интерфейсе есть метод запуска, должен быть и зеркальный метод остановки. И никаких "побочных эффектов". На досуге можно почитать "Совершенный код" Макконнелла.

[The Nameless One]

Dimka,
забыл уточнить, что класс Application - singletone.