Jon Stewart on 29 Jul 2003 00:17:44 -0000 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [ALACPP] Thoughts on last night's code sample |
> I don't know. Usually when I create events, I end up wanting to have > behavior on them, or at least a discrete type. Things like > serialization, etc. It just works better when they are discrete types, > because even if I have a generic serializer I need to somehow But defining serialization for an object is a big pain. We wrote serialization for all basic types, plus std::string and all the STL containers. With that done, we only had to write serialization for complex objects. Many of our messages were pretty simple, a token here, an IP address there, so a good deal of the time we didn't have to pay the serialization tax. In fact, a substantial portion of our bugs were when someone added a new member to a class and forgot to stream it. By contrast, if you added another argument to send, you couldn't compile until you'd sent and received it. > disambiguate between different kinds of events. You can use things like > inheritence to do some clever event dispatching. You also have the > benefit of actually knowing what all the events are in the system (nice > use for typelist) in a really unambiguous way. The biggest reason though > is it is just sooo much simpler (particularly when you are debugging), > and I try to place some kind of a premium on XP's notions of KISS. We used 2 byte ints for message IDs to disambiguate events coming over the network. When a NetObject was created, it registered the IDs that it would listen for. Perhaps a bit crude, yes. OTOH, it was also simple, and quite manageable using namespaces -- you could quickly get a list of all the IDs by listing everything in namespace "Pkt" (we used sub-namespaces). In our network topology, we had lots of different types of connections, depending on who you were talking to, and each type of connection typically had only a few messages it could send/receive. Those different types of connections were different C++ types, and that carried a lot of the type information that you'd normally get from having a big, generic event-handling system. It really wasn't a big, generic event-handling system. It was completely decentralized, so you weren't receiving an event from the central event-handling authority, you were receiving a message from Bob. And, hey, you know Bob, and Bob only knows how to say three things. Again, event handler is a bad name. We were really using it for type-safe, auto-streaming, tax-free RPCs. Given that we were simply using integer values for message identifiers, perhaps it would be possible to specify the integer value at compile-time as a template arg, in order to do some kind of checking? Some way that you couldn't mix-n-match handlers to the wrong events? To my knowledge, however, this never happened. No one ever decided to listen for A instead of B and A and B's arguments were the same. > If you hate making event objects though, Boost PP sure makes it a lot > easier to do argument-based events than any other solution (if anyone > mentions varargs I'll kill them), so I'll concede that this really a > question of design goals as opposed to the quality/correctness of the > design. Certainly. varargs sucks. Jon -- Jon Stewart stew1@xxxxxxxxxxx _______________________________________________ alacpp mailing list alacpp@xxxxxxxxxxx http://lists.ellipsis.cx/mailman/listinfo/alacpp