What's your preferred event handling setup?

[LB]

Having used only one event handling system ever (Bukkit), I made my own event handling system for my project and am quite happy with the turnout:
https://github.com/LB--/resplunk/wiki/Event-Handling

What event handling systems do you like? Have you made your own?

[10X9216C]

Recipe Spelunker is a C++1z game engine where the two primary goals are separation of client and server and maximum modularity. The client is effectively a render target that the server draws to, and knows nothing of any of the inner workings of the game (other than the bare basics).

Should read up on component entity system. Basically does all that already.

resplunk::event::EventProcessor<>
Why the "event" namespace if you are going shove "Event" into the class name.

[LB]

myesolar wrote:

Should read up on component entity system. Basically does all that already.

I know, that's what I plan to use for the client.

myesolar wrote:

Why the "event" namespace if you are going shove "Event" into the class name.

Haven't made up my mind on that yet. EDIT: Changed naming convention because you're right ;p

I should mention I was only trying to show my event handling system, everything else is in flux and not set in stone.

[LB]

I took the liberty of (briefly) researching a few other event systems:

Bukkit http://wiki.bukkit.org/Event_API_Reference
Events are delivered. Similar to my system, except uses reflection instead of TMP. Thus, the Listener interface is just a marker interface. It's nifty but a common mistake is forgetting to add the @EventHandler annotation to methods that handle events. Event class hierarchy is ignored - you have to manually call events for parent types if you want that behavior. Whether/how this actually happens for events called by the implementation is inconsistent, unfortunately, meaning you have to do lots of experimenting only to still not have every case covered.

SFML http://www.sfml-dev.org/tutorials/2.0/window-events.php
Events are polled. Single event class with a union for all possible event types. This avoids dealing with inheritance bunt introduces the problem of a god struct. For how few events there are however, I suppose it's fine for now, but it just seems so wrong to me.

Magnum
Events are delivered. No real event/listener class hierarchy, just classes with "Event" in their name as needed, and a member function to override to listen. This makes sense, since magnum is just a graphics library and you're expected to design your own (possibly event-driven) abstraction for your game/application.

JavaScript
Events are delivered. I would classify this as using lambdas, since you can use any arbitrary code per each event type and related HTML entity. This is actually a really neat side-effect of being embedded in web-pages, but not really applicable to other scenarios.

What else? Pros/cons?

[NoXzema]

GLFW is event driven. You set basic callbacks and then based on the callback called, you can setup a switch statement using event constants for that specific type. This is useful for optimizing the switch statements. Unfortunately, this method complicates threading. There's also not many guarantees as to how the callbacks are handled.

SDL is similar to SFML.

ASIO is also interesting in the way it drives it's events. It's so easy to setup on a pool, it's criminal not to use it in any IO-based situation if you're environment allows it.

[IWishIKnew]

Having to work with Java at work, I am hateing the event-driven programming I have to do: the library we're using has memory leaks, and I've never seen a single design pattern so overused to death.

This, however, looks like a very nice project... I may try it when I have the time.

[Albatross]

the library we're using has memory leaks

It's possible to have memory leaks in Java? O.o EDIT: Or are you using the JNI to run some other code? Or am I completely misunderstanding something?

-Albatross

[10X9216C]

Memory leak may not be the proper term, but you can definitely keep allocating memory, keeping the reference and never deallocating it. For example, code that only pushes values onto the back of an array, increasing it's size while never decreasing it any where else, it will eventually grow eating memory that it doesn't need.

    virtual void process(ServerSpecificEvent &e) const noexcept override
    {
        //blah is const
        //e.specific() returns const
    }
    virtual void react(ServerSpecificEvent >>>> const <<<< &e) noexcept override
    {
        //blah is non-const
        //e.specific() returns non-const <<<<< shouldn't this return const?
    }

Also wondering, if this is compiled as a separate library, would you still be able to add events? Since it uses templates, how does the processor determine which function to call if it doesn't know of that type?

[LB]

@Albatross
It's very easy to have memory leaks in Java. Bukkit's reload command causes plenty of memory leaks - there's a petition to remove it. Classloaders are a huge contributor to memory leaks - once a class is loaded there is no way to ever unload it.

@myesolar
It returns non-const to conform to logical-const instead of bitwise-const. As for separate libraries/plugins/etc I am very concerned - I am sure there is a way around it but it may make things a bit convoluted for me.

[IWishIKnew]

@Albatross

That was my understanding as well, but for a language that is supposed to "allow the programmer to not have to worry about complicated things like memory", it sure is a pain in the ass to manage when there is a memory problem in java... If they added "delete", all of my problems would disapear.

[NoXzema]

I'm okay without the idea of delete. I think the bigger issue with a missing "delete" is that it complicates limiting the lifetime of an object. So you end up with a bunch of "close()" methods that instead takes its place, then letting the memory go off into the distance. At the very least, I think it should be made easier to provide hints to the GC that the objects lifetime has expired and its intention is to disappear. Perhaps that would complicate usability though...

[LB]

Maybe something can be done about it in Java 2.x, but not in 1.x

[rapidcoder]

So you end up with a bunch of "close()" methods that instead takes its place, then letting the memory go off into the distance. At the very least, I think it should be made easier to provide hints to the GC that the objects lifetime has expired and its intention is to disappear. Perhaps that would complicate usability though...

So you want to replace manually invoking close() with some manually invoking delete() doing exactly the same? What's the point? How would delete() be implemented? Why would you ever want to make the object "disappear" immediately? What do you mean by "disappear"?

I think that you misunderstands how memory management works, either GC or manual. Calling delete in C++ does *not* release memory to the OS, only marks it can be reused by your program. In Java, unreferencing an object makes it reusable by your program. Therefore, you can imagine there is an implicit, zero-cost delete called immediately when you no longer reference the object - semantically they are the same.

[LB]

I didn't want this thread to turn into a Java GC discussion that we have had so many duplicates of.

[giblit]

NoXzema wrote:

rapidcoder, not only did you misrepresent my words, you insulted me.
You officially can go fuck yourself dude.

Was this necessary? Also, I don't see how he "insulted" you. He clearly stated a point.

When I use unity with C# they have a thing called a "delegate" you can use in an event manager. http://unity3d.com/learn/tutorials/modules/intermediate/scripting/events
Basically your other objects can subscribe/unsubscribe their methods to be invoked to it then when ever the event manager is triggered it will call anything that is subscribed to it.

[NoXzema]

giblet, you don't seem to know anything about C# or what a "delegate" is. Even though you probably do and I'm talking completely out of my ass.

Also insulting to claim that I said something when I didn't, which misrepresents my argument.

Also not the first time rapidcoder has done such a thing, so it becomes personal when the same thing from the same person happens continuously against me (regardless of whether he does it to others).

[z05DSL3A]

NoXzema wrote:

Oh, and since you reported my post, you can go fuck yourself rapidcoder.

It was me that reported you.

[NoXzema]

Then why do you even care? Why would you report me for that?

[z05DSL3A]

I reported you because of your language.

[giblit]

You told someone go fuck yourself when they provided information you didn't like then wonder why you were reported? No one likes when people flame.

Please refer to http://www.cplusplus.com/forum/lounge/6/

Feel free to participate in a constructive and polite way in any topic of this category.

and http://www.wisegeek.com/what-is-forum-etiquette.htm

Flaming, or deliberate insults or personal rants, is also against forum etiquette. Flaming is often employed by people who are losing arguments on a forum. Their response is to personally insult the poster disagreeing with them, usually in a long, nasty post.

This kind of behavior is why so many forums have a list of posting rules and consequences for breaking them. Some may say this behavior is more prominent among immature teens, but that is in no way the case. Many of the worst offenders are adults who should know better. The veil of anonymity seems to bring out the worst in these people, and any bullying tendencies they have tend to become magnified in the semi-protection of an anonymous forum.


Most of the rest of forum etiquette involves using the Golden Rule: treat others as you would like to be treated. Behaving as a reasonable adult, even in the face of being flamed, is always the best course of action. If a poster becomes harassing, obscene or personal, do not retaliate. Instead, cut and paste the offensive post(s) into an e-mail and quickly report it to the moderator or forum administrator.

I think you kind of derailed LB's thread now :(