You shouldn't construct std::set if you don't need its functionality.

Same.

It might be use std::unordered_map or similar in future.

This whole code can be replaced by:

m_pGUI[eventName].emplace(this);

it->second.empty().

You've already found eventName in m_pGUI.m_EventIGUIObjects, why search again?

Should the removed object get notifications? I suppose it's the dangerous place.

Don't even want to, but not creating segfaults

Don't see a removed object

that won't even compile

You don't need std::set for that.

m_pGUI.m_EventIGUIObjects[eventName].emplace(this).

std::unordered_set might wok better if we do need unicity, else vector

Ptr could be nullptr

m_pGUI.m_EventIGUIObjects.emplace(this).

You don't need to find something here, so no needs to use some kind of maps.

I suppose it can't be nullptr.

I mean can someone unset handlers during that call? If yes - then the behaviour was changed afaics.

I don't think anything prevents unsetting handlers at runtime, nor setting them, actually. I don't think it was particularly well defined before, but it's not now.

In theory one could unset handlers. However there is only a difference if we are removing on objects which used to be processed later and aren't brothers. One should question though if the original behaviour is right: the event was originally send when the object was in the list, so one might expect the event to be received. This actually seems to make it rather more well-defined than less.

Missing
(Breaks without PCH)

#include <set>