On Mon, 20 Apr 1998, James Turner wrote:
>The problem in this though is that you have incredibly annoying
>synchronization issues. Moreover, you can never guarantee, short of
>using huge mutex locks all over the code, than a valid target on line
>X will be valid on line Y. Also, synchronization of fights is an
You simply #define the function calls out of existance if you're not using
pthreads.
>issue. And unless some kind of slowdown is put on command execution,
>players with faster links will be able to do more commands than those
>with slower (as opposed to the current one command per player per pass
>in the main loop).
There wouldn't be a difference based on your link more than there already
is.
>It's messy. It would fundamentally change the code; supporting two
>versions wouldn't be nearly as easy as now, and just about every
>snippet would need a threads version and a non threads version.
You're the one that hates ASPELL/CREATE/etc and you're lecturing me on
messy?
>Things like GET_NAME(ch) = p, GET_STR(ch) = 10, etc., are bad as-is.
>There is no assurance that data assigned is valid. setName,
>setStrength, etc would be better ways to assign these.
Um, as I said previously, you want redundancy upon redundancy.
The code already checks what it is assigned to make sure it is valid.
If something slips by then you fix that section of code. C doesn't need
such Big Brother checking unless you cannot write a decent function.
If something is extremely redundant like GET_ROOM_VNUM(), then add it to
the macro or just write a function for it. But not everything needs it.
>gcc is picky, and stubborn, and somewhat obstinate sometimes, and
>inlining is one. It is rather ad hoc about it.
I do believe we're writing a MUD here, not exactly a speed-critical server
that requires inline functions. Anything that speeds it up without much
trouble is fine but inline functions do not fit in that category
(especially since they don't work when you define -ansi).
>> #define GET_STR(ch) (str_app_index[ch->str].tohit)
>>
>> Or you layer further down, just like functions do.
>
>There's no check to see if ch's str is valid, or if ch is a valid
>pointer, etc etc etc. Macros are bad.
ch->id = 1;
There's no check to see if ch is valid or 1 can be assigned to it.
C assignment statements are bad.
Would you prefer:
#define GET_STR(ch) (ch ? str_app_index[ch->str].tohit : 0)
>> Contrived example, in your case you'd either use a function or make a
>> smarter macro.
>
>>From a previous response,
>
>#define MAX(a, b) ((a) > (b) ? (a) : (b))
>
>top = MAX(x++, 4);
>
>Problems like this sneak into code, and make diagnosis sometimes
>difficult.
MAX() is a function in CircleMUD. EGCS will warn about double ++'s in the
future. Until then, don't hyper-pack your expressions if you don't trust
macros.
>> Um, if you see something that crashed on a line:
>>
>> strcmp(GET_NAME(ch), "bob")
>>
>> and 'ch' is NULL, what is the difference?
>
>If this line crashes, ch could be null, or ch->name could be NULL.
>There's no way to tell without checking data explicitly with a print
>statement in gdb.
It crashed, so by the context of the code you can tell what is NULL.
if (GET_IDNUM(ch) > 0)
if (!str_cmp(GET_NAME(ch), "Bob"))
You can tell 'ch' is not NULL, so ch->name must be.
And if you cannot tell which is NULL, add a check against both!
>Redundancy can be good. Error checking is better. I'd rather my
>player files not get corrupt by errant pointers or whatnot. NULL
>pointers won't do this, but invalid pointers can. It is dangerous to
>always assume pointers are valid (and non-null pointers can be checked
>for validity with, say, magic bytes).
Then manage your pointers better. Random pointers can still cause a crash,
corruption or other mischief, even with trying magic bytes.
You may get unlucky and the same memory gets reused...etc
(I've seen it.)
>Using assert() and defining DEBUG and such would take care of the
>performance issue on production builds.
'production'? I'd say most MUD's keep debugging info for unexpected
crashes and don't have to worry about performance.
--
George Greer - Me@Null.net | Genius may have its limitations, but stupidity
http://www.van.ml.org/~greerga | is not thus handicapped. -- Elbert Hubbard
+------------------------------------------------------------+
| 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