On Wed, 1 Nov 1995, Mark Coletti wrote: You /really/ like long posts, don't you? :) > Wout Mertens pounded furiously on the keyboard: > Well, now that you mention it, I did this a few days ago! =8-) > ----->8 snip snip snip 8<------ Kewl! Thanks! > > > o Reduce dependency on pre-processor wherever possible > > Duh? Why? > > The pre-processor is used to include files, to conditionally > compile code, and to define macros. I don't quibble with the first > two points, but the last one has some issues that could be raised. > (Which are admittedly mostly trivial. :) > > Macros are mostly used to define constants. With the advent > of the ``const'' keyword in ANSI C, it's really a better idea to > define constants as real variables that have ``const'' pre-pended to > them. The constant now is located in the symbol table, whereas it > wouldn't if you had defined it as a #DEFINE. This makes debugging a > bit easier. And the code larger :) (Hmm, not that much tho.... Ok. You have my blessing on this one :) > > > o Simplify header files by moving as much as possible to > > > implementation files > > You mean things like AFF_INVIS should not be in structs.h but in > > mudstuff.h? > > Actually, there are a lot of things that could be done to the > header files: <snip> > o global header files are Evil! Break them up into separate, > meaningful header files. I would *love* to see you transform structs.h to something less global :) Ok, a few structs can be moved to other places, like the save structs, but still... > > > o Introduce opaque types to reduce code complexity > > struct char_data -> char_data? or what do you mean? > > Gak! I _knew_ somebody was gonna ask me about that! 8) <object oriented stuff deleted> Thanks for typing it out :) I wonder if someone will ever convert the mud to c++? Must be a hell of a job. > > > o Rely on lex and yacc for command line parsing > > Why? Isn't it better to make our own parser that will take things like "P s" > > as a format id for a function expecting 1 player and a string, that will > > process errors and such? > > Nope! I would rather write a parser that used lex and yacc > (or any of their progeny). That way I could create more flexible > syntax that would probably be parsed with fewer errors. Why re-invent > the wheel when there's one already around that works extremely well? Weeell, there was Stroustrup I believe who was feeling sorry for himself for using yacc and lex for his compiler... (Don't quote me on this! I'm not sure it was him. Someone was sorry anyway :) I think that they are a bit more difficult for decent error checking... I could be wrong tho. And then there's still the auto-abbrevving, which I think is a very good feature, that will be lost... *waves*, Gekke Eekhoorn of BUG.
This archive was generated by hypermail 2b30 : 12/07/00 PST