Re: Circlemud design issues

From: Chris Jacobson (fear@ATHENET.NET)
Date: 04/19/98

On 4/19/98 2:52 AM, James Turner (turnerjh@XTN.NET) stated:

>and such, and I've been very impressed with the level of support
>offered to newer coders.  It's reassuring to see a such support (with
>no/few flames, no less).

Thats one of the reasons I stick around the list - about 1/4th of the
topics are of interest and/or worth reading, which is a much higher ratio
than other lists.

>However, I think there is also room for higher level discussions.

About time somebody brought this up :-)

>1. The biggest issue in my opinion is the use of macros.  Macros

Well, if the codebase was moved to C++, macros would be obsolete - I have
done most of this kind of work myself.

>(Additionally, for speed issues, gcc allows for the inlining of
>functions, even in C code.  Perhaps VC++ provides a similar facility,

Any compiler worth its weight in salt will support inlining, among other
necessary features for a more advanced, object oriented programming.  If
a compiler supports templates, it most definitely supports inlining,
since inlining is the root of templatation (sounds a bit biblical, no?

>2. Expandability.  Circlemud provides a great platform for newbie

And kudos to George for his excellent work in providing snippets and an
organized snippet site to the CircleMUD community!

>3. Layout.  The code in circlemud is, to be honest, poorly laid out.
>The file divisions are usually fairly accurate, though there are many
>contradictions and oddities in the code that make it hard to
>understand what functions belong in which files.  I personally use

This was a problem I also saw, but my move to a C++ structure required a
fair amount of reorganization.  Almost all character-related functions
are now in a single file.  Room related functions in another...  Etc,
with the exception of the get_* functions being in "find.c++"

>design issue that needs addressing.  Also, we need a single .h file;
>having several is a real problem.

Well, for some it poses a problem to have multiple header files, for
others, such as myself, it is a blessing.  A recent check of my files
turns up 60,000 lines of code (with an additional 10,000 blank lines -
and I use a compressed code format - my own format of indentation which
reduces line count by at least half - rather than the standard that
CircleMUD ships in).  My compiler, CodeWarrior Pro 2, also reports total
lines it processes for each file, and the total lines processed in a
compile.  My average file processes 20,000 lines... and I have the
original "structs.h", "db.h", etc, files broken down into about 12 more
seperate files, half of which are included in every file.  The fewer
header files, the more code in each file, the greater the chance that any
given code file will have to be recompiled if any given header file is
modified.  Thus more files must be recompiled whenever a piece of a
header file is changed.

>Another layout issue are player directories.  I personally like having

A valid concern... but something many have already taken care of.
However, merging a better solution into the stock codebase is perhaps
preferrable to providing patches which the majority of people would use.

>4. Redundancy.  Many redundant functions have snuck into Circle.  The

A Standard Template Library should be adapted for this purpose, or one
written (I have chosen the latter, since I couldn't find any STL that
provided the exact linked list system I needed: one which was
iterator-depth safe - i.e, multiple iterators and sub-iterators allowed,
and removal or addition of an item will not throw off the iterators, but
rather, will update them)

>5. Unix tools.  I can't say how many times I've seen patches posted

PERL is always a good solution, as it is available on all platforms, and
scripts are (mostly) write-once run-anywhere.  Besides, there aren't too
many UNIX tools needed.

>everyone reading this should go download Emacs.  It's hard to learn in

If you have a MacOS, Win95, or WinNT station, I recommend CodeWarrior.
It is far superior to any development environment you will find, and
costs only $400 ($100 for students).  I'm sure anyone here who has used
CodeWarrior will agree.  Plus, coding locally in a full GUI, with
multiple windows, searches, and more, is much more efficient than coding
remotely via telnet and vi/emacs/joe/cat/grep/whatever.

>6. Code appearance.  Circle is in most cases readable; however, there
>are times it isn't.  In particular, the use of typedefs can simplify
>things.  Also, we need to get rid of ACMD and ASPELL (something I did
>straight off).  They are a convenience in the initial writing of a

What would you replace these with?  The only real solution is to replace
them with the full syntax, which will increase filesize and decrease

>command or spell, but they are an abuse of notation, so to speak, and
>can cause problems with symbolic debuggers as well as cross
>referencing programs.  Generally, for every time you're lazy when you

I have yet to see a symbolic debugger or profiler (of two drastically
different kinds of each that I have used) that has had a problem with

>mistake or some other issue ;)  Also, it would be nice if all the code
>conformed to one style.  I have an indent script I use for my own

Almsot everyone has their own personal style, and no script can produce
perfect indentation - there are always exceptions.

>7. Linked lists.  The current linked list support is, well, somewhat
>dirty.  Imbedding next elements into all the structures then using the
>REMOVE_FROM_LIST macro is extremely ugly.  We need to get a simple
>linked list library written (a fairly simple task), or use one out

See response to #4.

>there.  I personally use the singly linked list class from glib (a
>subcomponent of gtk, which provides a large amount of common C
>algorithms and structures, including hashes, lists, and I believe
>trees), which is exactly what we need.  The only downside is that,

Where is GTK available from?  I assumed it was a GNU package (given the
undescriptive name, and the g- prefix), but it is not listed on the GNU
ftp site.

>though glib itself is cross-platform I believe, gtk probably doesn't
>port to Win32 yet.

If I can find it, I'll see if I can port it to MacOS.

- Chris Jacobson

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST