[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