Chris Jacobson <fear@ATHENET.NET> writes:
> >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.
Personally, I feel that a C++ conversion would not be the way to go.
Circle is, and has always been, a C codebase. Doing a conversion
would not be the right way to go -- it wouldn't be Circle anymore.
Converting a 50,000 line codebase to C++ would either result in one of
two things. One, a C codebase made to look like C++ without using it
to its full capabilities. Two, an entirely new mud.
If C++ is really desired, I think there are several muds designed this
way from the ground up. I have nothing against the C++ language -- it
is very good. However, at this late time, converting to C++ would not
be the way to go.
That's not to say we can't use object oriented design philosophy. For
intance, data abstraction is something I am heavily using in my
current code base. Yes, it results in a large number of functions,
but they are both more readable as well as flexible enough to allow
for later changes to the underlying data structures without having to
change every line of code.
> 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?
> :-)
Certainly, most do support inlining. As George pointed out in another
post, gcc supports it with -O3 and -finline-functions. However, those
optimizations are done by the code on what functions it feels should
be inlined. The optimizer in gcc (and its derivatives) is very good;
however, it is not that good. It only has compile time information to
go by. We need to be able to explicitly request some functions be
inlined (which gcc supports, even in C).
> 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++"
Moving to C++, if done properly, would need a complete
reorganization. Truly using the power and philosophy of a C++ design
would require a _lot_ of work, and would result in something that
resembled Circle only because that is what it happens to be named.
Anything less would defeat the purpose; C++ shouldn't be treated as C
with classes. It is a very different language that is mostly
backwards compatible. But using C++ like a procedural language is
like using goto and labels in C code instead of its loop directives
(for, while, do).
> 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.
This has been pointed out to be. My own code base is organized into
structs.h, protos.h (generated automatically on demand; very useful,
if anyone would like the simple script or makefile entry, say so), and
externs.h. You and George are right that this does significantly
increase the compile size; however, it simplifies the coding.
Further, compiling a header takes a LOT less time than compiling
normal code. They are declarations, not executable code. A 20k
header compiles significantly faster than a 20k code file.
> >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.
There are a lot of patches out there I think. But we need a specific
one. I'm not saying mine is the best; however, I've found it much
more manageable.
> >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)
We can easily achieve a standard library without resorting to the
STL. Circle has a lot of what it needs; it just needs a little bit
more work.
(I'm too wordy and I've had to break this up into two responses :) )
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST