> "bad" is relative. Do you use a global variable or pass around 13 > different variables you don't care about? Depends on how your like your code to read :) I'm not a fan of static variables, and prefer parameters. The various arguments I've seen to date against 'buf' which mostly run along the lines of 'possibility of data corruption, or the accidental use/display of old data or data from another function' can be prevented. To me it makes more sense having a standard (this being the operative word) buffer system used throughout the code be it dynamically allocated (but would we always want this?), or static, than passing parameters willy-nilly all over the place. I agree with a comment that someone else made earlier in the discussion that maybe for people new to CircleMUD and C coding in general, there should be a few variable name changes if we decide not to change the system. eg. 'buf' becomes 'gbuf' and is documented in such a place that someone new will read about it without having to fall over it accidentally smack bang in the middle of the code, and functions that currently use a locally declared 'buf' be renamed to 'lbuf'. BTW these names are only used for illustration and not ones Im necessarily suggesting we use :) I must admit, all discussions aside, Im more interested in what you George are contemplating we change to :) > I suppose then it becomes a > matter of what IS your design? Which is probably what you are asking people since the pro's and con's are going to be mostly personal, dependant upon a persons coding style. Hopefully someone is going to prove me wrong and come up with strong arguments for, or against 'buf' being global - but I havent seen any so far, and don't have any to add myself. Either that is my agreeable nature or the fact that my brain went to sleep 1 hour ago and forgot to tell me. :) -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST