On Mon, 20 Apr 1998, James Turner wrote:
>That's not the answer either. However, there is middle ground, and I
>feel I've reached it in my code. It simplifies the above and makes it
>easier to follow what the code does.
What do you have so we may comment on it?
>It's more clear what the data actually is. The struct makes it harder
>to follow, makes prototypes and declarations longer, and distracts the
>reader from what actually is being declared.
As was already said, it can make it harder to read. I like to know that my
structure is a 'struct' and isn't yelling at me for no reason. Data types
shouldn't be capitalized without regard.
>I can make ACMD's for things that aren't commands. Just because it is
>declared that way doesn't mean it IS a command. Call the functions
Just because I declare something to return 'int' doesn't mean it has to.
(See getc() for an example.)
You're arguing pedantically.
>do_* or cmd_* or whatnot. As for changing the spells and commands --
>if your making the change in the structure just for one or two
>commands, you're probably going about it wrong. If most commands will
>take advamtage of the changes, then you need to go into each function
>anyway.
But then you won't need to change those that don't use it.
>> Which is easier to maintain?
>
>Either that has the parameters clearly declared in the declaration and
>not hidden by a macro, though I prefer the latter. Be honest, how
>likely are you to need to change the declarations without changing the
>functions themselves? Besides,
Often, how many spells and commands actually use the command number?
Few, but some do need it.
>No. A prototype generating script, or a sec script, will expand them
>in-place to proper functions.
Personally I turn on -Wmissing-prototypes and take the compiler warning.
>> I'm assuming you don't like CREATE() either then.
>
>CREATE is gone from my code also, replaced with void *mud_calloc(int,
>int). It wasn't that difficult to replace all occurances in the code
>with proper functions -- five minutes work with emacs.
Although it's most likely uglier now.
>Not that much unnecessary casting -- it can be hidden with wrapper
>functions and thereby ensure type safety. As for traversing a list
>given an arbitrary member, how often is that necessary?
You're given a person, find who is in the same room.
>> >From structs.h:
>> struct char_special_data char_specials; /* PC/NPC specials */
>> struct player_special_data *player_specials; /* PC specials */
>> (*)struct mob_special_data mob_specials; /* NPC specials */
>>
>> (*) - Could be a pointer though.
>
>The current arrangement is suboptimal (to put it mildly). The weak
>inheritance would IMO be more efficient, more clear, and make it
>easier to expand later on. Plus, there are way too many embedded
>structures anyway.
You're talking C++ again unless C has inheritance now. Embedded structures
are not evil although I don't argue the current arrangement isn't the best.
--
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