[MUD-Dev] [adv-mud] Re: Topic list repost (fwd)
J C Lawrence
claw at kanga.nu
Thu Jan 20 15:40:55 CET 2000
------- Forwarded Message
Date: Thu, 20 Jan 2000 16:06:31 -0600
From: Chris Jacobson <fear at technologist.com>
To: "Advanced MUD Design" <adv-mud at egroups.com>
On 1/20/00 2:22 PM, Erwin S. Andreasen (erwin at andreasen.com) stated:
LexiMUD 0.3 (http://avp.dhs.org/leximud) features some things that may be
of interest:
>STL
I have implemented my own derivative of STL. It is fully compliant to
the STL interface, and is safe for drop-in use in existing MUDs. To do
this, one of the things I did with <list> is to make the nodes reference
counted and "purged"-flagged (which causes iterators to step over the
node). As for the other classes, well, doing something like this with
<vector> would involve a little more overhead, and the preferred
mechanism for accessing a <vector> is incrementally with numbers (hence
why the optimized <vector> uses vector<>::__start and vector<>::__end+1
for its begin() and end() iters).
The implemented classes include <list>, <vector>, <map>, <multimap>. So
far these classes pass all the STLport tests that I have thrown at it
(although I haven't fully tested <vector> with the STLport tests, it runs
great in the MUD). There are other important portions of the STL
included as well, and it supports the full type_traits and
iterator_traits scheme.
The LexiSTL is in lexi/stl.
>Strings
I have a semi-tested String class in lexi/src/string.{h,cp} Strings are
reference counted and use a sub-string mechanism to allow for optimum
memory efficiency, and the operations are a bit optimized towards the
mechanism. All Strings are effectively substrings, referencing the
internal String class, and storing the offset and length. These strings
are also compatible with C strings in that attempting to access them in
C-like ways causes them to convert themselves over to a single-reference
of only the content string itself (thus de-referencing the shared string).
>Virtual overlaid filesystem (not REALLY an OO issue, it just happens the
>thing is implemented in an OO way)
I'd love to see something like this, and if I ever get the time I might
even do it.
>gcc switches, gcc vs egcs, -fexternal-templates or not
Isn't this a NULL issue with GCC 2.95 being done by the EGCS committee
(GCC is Dead, Long Live GCC)
>OO Interpreters
>Pointerless Muds
>Non C++ OO implementation/how-tos
This brings me to something I've been looking into - reimplementing the
whole codebase in Python <g>. I bought the book Erwin recommended, and I
love the language.
- - Chris Jacobson
------- End of Forwarded Message
--
J C Lawrence Home: claw at kanga.nu
----------(*) Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev maillist - MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list