James,
What does the example you give have to do with Macros?
Your first example could be a Macro (the char_in_room(ch)) and the function
still requires knowledge of the *next pointer.
Your second example needs more code to make sense. How are
chars_in_room_iterator(), next(), and iter_to_ch() defined for the present
structure?
All you have to be careful, C give you enoungh rope to tie a couple of nooses,
just don't put you neck into it.
--Angus
______________________________ Forward Header __________________________________
Subject: Re: Circlemud design issues
Author: INTERNET:CIRCLE@POST.QUEENSU.CA at CSERVE
Date: 4/21/98 9:32 AM
> That would be cleaning up code and making the stock code much more solid
> than it is now. Not deciding wether GET_BLAH should be a function or a
> macro. In most cases it would be just cosmetic.
Not true... it isn't always cosmetic. Macros have major shortcoming
when it comes to changing underlying data. By this, I do not mean
simply moving an entry in a structure to a substructure or whatnot. I
mean something like drastically redoing the way structures are laid
out. Suppose the decision was made that an array of rooms isn't the
best way to go. Right now, all the code that does
for (tch = world[ch->in_room].pepople; tch; tch = tch->next_in_room)
...
Would need overhauling. But if it had been done originally like:
CharList *l;
for (l = chars_in_room(ch); l; l = l->next) {
blah(l->ch);
...
}
Or another way,
Iterator i;
for (i = chars_in_room_iterator(ch); i; i = next(i)) {
tch = iter_to_ch(i);
blah(tch);
...
}
Data is hidden. We don't directly poke into the world array. We
don't repeat code. It's nicer, more elegant, and easier to read,
though the second adds a very slight kludge. We could define macros
to make this easier, though normal functions will do just fine.
+------------------------------------------------------------+
| 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