Глупый вопрос про удаление объектов

Если память не шлюха, то man The Phoenix Singleton.
http://www.cs.gmu.edu/syllabus/syllabi-spring03/cs332-kaznachey/12/Class12Gen...

эм... уничтожать Log после TcpLinkManager ?

Тот пытается вызвать метод объекта Log для записи сообщения. Но объект Log уже уничтожен.

Делать проверку на то, существует ли Log?

QObject::disconnect

Какой есть способ «красиво» решить проблему?

Экземпляры TcpLinkManager и Log сделаны ввиде глобальных переменных

глобальных переменных

я думаю ты догадался, в какую сторону копать?

сделать правильный дизайн, без глобальных переменных, удалять объекты последовательно

QObject::disconnect(), не?

и не надо делать глобальные переменные, это ад и израиль

Если бодробнее то Андрей Александреску, «Современное проектирование на C++» Глава 6. Реализация шаблона Singleton. Там рассматривается именно ваша проблема.

Когда уничтожаешь глобальный Log:

delete LogInstance;
LogInstance = NULL;

В коде записи лога

if(LogInstance!=NULL)
{
    ...
}

Но вообще глобальные объекты это плохо.

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

Делаешь управленца сервисами, который предоставляет глобальные объекты. Инициализируешь и уничтожаешь его в main, для всех остальных он «глобальный», он же предоставляет тебе другие глобальные объекты, он их сам создает и сам уничтожает в нужном порядке.

я думаю ты догадался, в какую сторону копать?

Да что вы все повторяете эту мантру. Если ты внимательно посмотришь, то поймешь, что дело не в глобальных переменных. Можно привести пример, где глобальные переменные отсутствуют, а ситуация полностью аналогична.

«NULL» тоже бы не надо…

Если с++11, то можно nullptr.
А если старый стандарт, то что тогда может NULL заменить?
И почему не стоит использовать?

Если объекты не глобальные, то можно точнее управлять их временем жизни. У тебя TcpLinkManager явно зависит от Log. Следовательно Log не должен уничтожаться раньше, чем TcpLinkManager.

Напомни, почему нельзя просто проверять как-нибудь вот так:

if (!ptr) ...

Нулём, не?

>И почему не стоит использовать?
В C++ дважды не Ъ, сам по факту и по факту бытия макросом.

попробуй QObject::deleteLater

Если объекты не глобальные, то можно точнее управлять их временем жизни. У тебя TcpLinkManager явно зависит от Log. Следовательно Log не должен уничтожаться раньше, чем TcpLinkManager.

То, что ты говоришь разумно. Но я бы хотел исходить из равнозначности объектов в плане их создания и уничтожения. Ведь не всегда можно сразу сказать, что объект А должен быть инициализирован раньше, а уничтожен позже чем объекты B и C. То есть необходимый порядок их создания не вытекает строгим образ из функциональности и логики работы объектов.

попробуй QObject::deleteLater

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

Я пока склоняюсь к идее двух-этапной инициализации, когда помимо конструктора/деструктора есть ещё пара методов Init()/Close(). Close() должен сделать объект «пассивным», то есть таким, чтобы при уничтожении не порождал сторонних эффектов на другие объекты.

Думаю для TcpLinkManager в методе Close() достаточно будет закрыть сокет и заблокировать повторную установку соединения.

Ведь не всегда можно сразу сказать, что объект А должен быть инициализирован раньше, а уничтожен позже чем объекты B и C.

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

Зато NULL легко заменить на nullptr, а вот с 0 это так просто не прокатит.

Вообще можно, но на мой взгляд код

if(ptr!=NULL)

более читабелен.