Daniel Koepke <dkoepke@california.com> writes:
> > 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.
A loop through the character list is a very slow loop as it has almost
no locality of reference. Likewise with other loops. Do you know
what a tight loop is? Do you understand what qualifies as one and
what doesn't?
Do you have any concept of how long things take on cpus, even 386s? I
suggest you sit down and play with a profiler and maybe spend some
time learning about how modern CPUs operate, and the speed at which
they operate.
> > 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.
I do advocate breaking away from REMOVE_FROM_LIST; however, that is a
different discussion.
How do you feel that
#define CREATE(result, type, number) do {\
if (!((result) = (type *) calloc ((number), sizeof(type))))\
{ perror("malloc failure"); abort(); } } while(0)
Is more newbie friendly than
void *
mud_malloc(size_t nbytes)
{
void *p;
assert((nbytes > 0) && (nbytes < 5*1024*1024));
p = malloc(nbytes);
bzero(p, nbytes);
if (p) {
num_allocs++;
bytes_alloc+=nbytes;
return p;
}
sprintf(errbuf, "mud_malloc failure for %d bytes", nbytes);
perror(errbuf);
abort();
}
Or that
CREATE(buf, char, 80);
is more newbie friendly than
buf = mud_calloc(80, 1);
The CREATE macro does NOTHING for newbies. It is a nonstandard
construction. It will only slow their learning of C.
> > 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.
Can you read? I did not say macros in general were hacks -- I said
"but the way Circle use then is as short-hand hacks that really have
no place anymore." Circle uses them as a shortcut around and short
circuit between the two alternatives: direct access to the structures,
or using true accessor functions. The former is no better than macros
for handling data, and it unnecessarily ties code to internal data
representation.
> > 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.
#define ABS(x) ((x) > 0 ? (x) : -(x))
int
next_datapoint()
{
static int i = 0;
return data[i++];
}
x = ABS(next_datapoint());
Do you see the problem? Run it through your C preprocessor if you
don't. Macros have very odd properties that can cause a lot of
trouble if you expect them to behave just like functions. And there
are a lot of other examples, particularly with improperly written
macros. As circle uses them, macros don't suffer from this in most
cases. However, they can still have rather unpleasant side effects.
(continued next post)
--
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