Daniel Koepke <dkoepke@california.com> writes:
> > 1. The biggest issue in my opinion is the use of macros.
>
> Macros are the _only_ way to encapsulate code you want to inline. A
> function call is still costly. It is absolutely ridiculous to make a
> function call for a single line of code, and macros offer flexible
> functionality that functions do not.
The overhead for such a function call is negligible. If it were
something called frequently in a tight loop, then perhaps; however,
that is not the case in circle. As for it being ridiculous to make a
function call for a single line of code -- many of the macros could be
expanded upon into more than one line. Or, if later needed, added
error checking could be added. Further, it is impossible to profile a
macro; functions, though, you can get exact profiling information on.
As for added flexibility -- what added flexibility is gained from:
#define GET_AC(ch) ((ch)->points.armor)
None. Yes, there are other uses for macros -- ones that the C language
itself can't provide otherwise -- but the way Circle uses them is as
short-hand hacks that really have no place anymore.
> As for how macros are expanded: this is a matter of writing good
> code. If you don't write your macros right, they won't expand how
> you expect them.
On the flip side, bizarre macro side-effects only make circle harder
for newer coders to understand. And, though you may not like or care
that there are people who learn or improve their skills with circle,
it happens quite frequenly.
> Inline functions are part of the C++ standard. However, just because a
> function is called inline does not mean it will be. The compiler is
> still in charge of determining whether or not a function should be
> inlined. This has the single advantage that the compiler can define
> different rules for different platforms.
You're right, it is a C++ standard, but it is extended to C by many
compilers. And declaring a function inline doesn't guarantee it will
actually be inlined (in particular, with no optimizations on, gcc
won't inline anything, even if explicitly told to). But it gives a
better chance than simply relying on the compiler to guess which
functions to inline and which not to. But speed isn't really the
issue -- many of circle's macros involve multiple pointer
dereferences. This can slow down a system as much as a function call
to the point where the added overhead of a function call would not be
that large compared to the time of the other operations.
> > 2. Expandability.
>
> This is why the code is there. CircleMUD is meant as a base system.
> People add their own code to it, and patches offer functionality that
> is desired by others but not a part of stock for one reason or another.
You're absolutely right. However, it is not perfect, and there is
certainly room for improvement.
> > 3. Layout. The code in circlemud is, to be honest, poorly laid out.
>
> Why is having several header files a problem? Multiple header files
> have the benefit of only requiring you to recompile code that is
> affected by header file changes. For many people, compilation time
> is not trivial and recompiling the entire MUD every time you want to
> change a function definition or macro is not desirable.
Having multiple headers can be good or bad; there are advantages and
disadvantages. I prefer a single header file for the headers
included in every .c file. Some logical breakdown can be of use, but
regardless of that, the organization of circle is somewhat lacking.
> I don't see any problem with CircleMUD's implementation of linked
> lists. It's _MUCH_ cleaner and more readable than a generic linked
> list library written in C (or a linked list template in C++) would be
> and it provides all the functionality required.
For every list you want a given character to be in using stock lists,
you need an added member in the char_data struct. It is _not_ much
cleaner; in fact, it is plain ugly and inelegant. Moreover, it would
facilitate the breaking of char_data up into two "inherited" classes
much like in C++ (details of what I mean are in other posts in this
thread).
--
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