What's your preferred event handling setup?

[NoXzema]

Would you prefer me to tell rapidcoder to screw off instead?

[z05DSL3A]

Would you prefer me to tell rapidcoder to screw off instead?

I would like it if you didn't get emotional about a perceived insult.

[NoXzema]

I derailed it? Not only did rapidcoder start this stupid discussion by going off on a tangent about memory management but somehow I started it suddenly.

According to your definition, a disagreement needs to happen for me to flame over. But rather, I'm just upset that he doesn't even comprehend my argument in the first place and instead chooses to twist words to make me look ignorant.

[NoXzema]

Whatever. This is literally the original reason I left the forum.

You do not sit there and insult someone's intelligence because you cannot read correctly. You especially do not make ridiculous assumptions about what people meant and then claim their ignorance or lack of understanding, when you don't even have enough context to make such assumptions.

You shouldn't generally challenge anyone's intelligence in the first place but rather their ideas.

[codekiddy]

I use libsigc++ (Callback Framework for C++)

http://libsigc.sourceforge.net/

It's easy to compile from source on windows and linux as well, the API it self looks clean and also it's easy to learn and implement.

example c/p:

class AlienAlerter : public sigc::trackable
{
public:
    AlienAlerter(char const* servername);
    void alert();
private:
    // ...
};

int main()
{
    AlienDetector mydetector;
    AlienAlerter  myalerter("localhost");	// added
    mydetector.signal_detected.connect( sigc::mem_fun(myalerter, &AlienAlerter::alert) ); // changed

    mydetector.run();

    return 0;
}

[NoXzema]

For IO-based interfaces, I usually use a C callback struct or a C++ virtual interface, then a FIFO queue of execution.

[10X9216C]

@NoXzerma
That is rabidcoder's way, all he does here is stroll C++ and then tries to take the high road to justify it when he's called out for it.

It returns non-const to conform to logical-const instead of bitwise-const.

Reacting to an event, means you are changing it in some way before it gets processed right? It just seems in that situation the whole event should be non-const. But when you are processing an event you shouldn't be modifying the event it self, right? Or do i have that backward.

[LB]

You have it backward for sure, processing always happens before reacting.

In other event handling systems, you have to have duplicate listeners with different priorities. For example, with Bukkit:

@EventHandler(priority = EventPriority.NORMAL, ignoreCancelled = true)
public void onJoinA(PlayerJoinEvent e)
{
    //process event
}
@EventHandler(priority = EventPriority.MONITOR, ignoreCancelled = true)
public void onJoinB(PlayerJoinEvent e)
{
    //react to event (and promise not to change it)
}

Only plugins process events, not Bukkit, and there's no way to differentiate between calling an event just to have it processed and calling an event normally. This results in a lot of conflicts between plugins.