[MUD-Dev] Data Storage and MFC Questions
david.l.smith at home.com
david.l.smith at home.com
Sun Mar 11 12:03:41 CET 2001
Ben Chambers [bjchambers at phoenixdsl.com]:
> What is the best way of storing the data for a MUD. I know that
> the most common is probably arrays or hash tables. Hash Tables,
> from what I understand are arrays that have a faster lookup because
> of the hash function. Which one do you use, and why? Also, has
> anyone ever tried using MFC to write a MUD server? For example, I
> have found the MFC Map, which is basically a wrapping of a hash
> table, as having a good chance for usage in data storage. You
> write a subroutine as part of the class describing the hash
> function for a specific type of data. Then you just add data by
> index and value. And you can reference by index, or delete by
> index. It is a very easy way of using a hash table. MFC also has
> prospects in other aspects of MUD Design. It allows for the
> simplification of many processes, including dynamic object
> creation.
Hmm,
MFC CMap <almost identically equal to> std::map<T >
I've found that the dynamic object creation pattern in MFC is really
one of the *only* reasons to prefer it over straight c++ and the std
library. However, if you look at MFC's rules, there's a lot of
trade-off to not rolling your own implementation for that kind of
thing. First, MFC's *not* using rtti, rather it's using an
object-hierarchy enforced type info system. Rtti's part of the
language (and portable), plus if you start a good object hierarchy you
can get the nifty parts of MFC (dynamic object creation, good
exception and memory handling, rtti, and serialization) using
platform/compiler portable code.
As for the object hierarchy itself that MFC gives you, I've found
everything I need in a combination of the Qt library and the ACE
library (Qt for my windowing, ACE for communications and threading --
especially threading).
Just MHO,
-Dave
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list