James Turner wrote:
>
> 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.
And now go look at how many of all of those macros are called in loops
throughout CircleMUD. Sure, CPU isn't _that_ big of a concern for most
MUDs. But some people have CPU limitations set by sysadmins, etc. You
are simply assuming too much. There's no signifigant reason to expand
macro code into more than one line in stock CircleMUD. And if people
need to do calculations that may get ugly in macros, they can easily
create functions to replace the macros.
What exactly are the benefits of rewriting macros as functions? The
only things you've really said so far is that they are a "hack" (I'll
address that point later in the message) and that in some cases they
are almost as slow as function calls and that sometimes the
additional flexibility they offer isn't needed.
> As for added flexibility -- what added flexibility is gained from:
None for that particular situation in stock code. However,
REMOVE_FROM_LIST is one case where the functionality could not be
reproduced in a function call without rewriting a lot of code (and you
suggested that all of that code be written, too). Also, rewriting
CREATE as a function would only offer the benefit of error-checking,
taking away from the newbie-friendliness of the macro.
> 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.
How are macros a "hack" when they are a well-established part of the
C language standard? How are they a hack when 99.9% of the majority
of programs use them? If macros are hacks, then please, define "hack"
for me, because your definition is obviously different from the one I
am used to.
> 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.
There are no "bizarre macro side-effects". Who's hat did you pull that
from? And I admire your subtle attempt to setup some type of "this is
good for newbies" defense, but nothing you have suggested will do
anything but confuse newbies.
> You're right, it is a C++ standard, but it is extended to C by many
> compilers.
Which are those? GNU C. Uhhh...and...? I can't think of any more.
It's certainly not ANSI C, and part of CircleMUD's reason for
existence is portability.
> 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.
Oh, so because some macros are _almost_ as slow as functions, you should
make all macros at least as slow as functions. That's logical...
> You're absolutely right. However, it is not perfect, and there is
> certainly room for improvement.
Well "perfection" isn't exactly a realistic goal, now is it?
> 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.
How is Circle's organization lacking? Please elaborate.
> For every list you want a given character to be in using stock lists,
> you need an added member in the char_data struct.
Adding a pointer to a structure is hardly as ugly as having a 100+
lines of code dealing with void pointers for 'data' and using
function calls for everything under the sun, as would be necessary
for any kind of generic C linked list structure. Playing "hide the
'next' pointer" in an "abstract" class is hardly going to make the
code cleaner or more newbie friendly.
-dak
+------------------------------------------------------------+
| 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