"Daniel A. Koepke" wrote: > > On Sun, 28 Jan 2001, Peter Ajamian wrote: > > > Why bother when all you have to do is declare your variables at the > > beginning of the function? > > Not to debate the usefulness of certain features of the C standard (but > the irony noted when contrasting these stances with the EXIT_FAILURE > debate), Do you really want to drag the EXIT_FAILURE debate back on the board? I had dropped the issue but... > but there are clear benefits to this. The first is that it > simply makes more sense to have declaration near use and increases the > structured nature of the program. Yes it does, but it is a minor cosmetic improvement compared to the loss of portability that you will incur. > There are also efficiency benefits, but > that's not a good reason in-and-of itself in the case of muds. Any compiler that has any kind of decent optimization will eliminate any efficiency benefit that decalring a variable mid-function has. > > It keeps things way more portable that way. > > In theory. For now. It is a part of the new C standard and, thus, will > eventually come into wide-spread support. We are dealing with now, not eventually. Currently there are too many compilers that don't support C99 or that require special switches to do so. > Legacy platforms that don't > keep up have a funny way of falling out of common use when programs start > appearing that benefit from adhering to new standards. Yes, but there's always a few that remain to irritate you at the most inopportune moments. I know of people who have gone through the trouble of compiling and running CircleMUD on ancient Unix platforms that only have an old version of cc. Sometimes a person does not have a choice of what platform to use but must use the one that is available to them (ie. beggars can't be choosers). Realizing this, it becomes apparent that sticking to a few simple, though perhaps outdated, rules will make the lives of those people much easier. If it's a case of only being able to code to support either an old standard or a newer one that is more widely in use, then I would agree to code for the newer standard. However (correct me if I'm wrong) it is my understanding that any program that adheres fully to the older ANSI standard will also adhere fully to the newer C99 standard, though the opposite ceartainly is not true. > That said, I > wouldn't push adherence to C99 to anyone, yet. I'm not aware of any > compiler with completed support and it will take time for C99 code to be > portable. > > > *Wonders why people have to insist on breaking thier programs > > Well... they are their programs. As any good (professional) programmer > knows, code is written for people, not computers. (Any programmer with > great job security knows this and abuses it.) Now if you're intending to > write code that is going to be supported by legacy platforms, then avoid > things that are a part of the C99 standard but not ANSI C. But if you're > writing for portability to newer platforms and prefer the style and > benefits of C99 additions... it's your program's portability to break. When it comes to advising newbie coders I would always advise them in the direction of keeping thier code portable. Yes it is your choice to do whatever you want, but I'm not gonna advise you to go jump off a cliff whether you want to or not. > > etc, etc, and yes, it is stupid, because it's so easily avoidable.* > > Avoidability does not a stupid thing make. It is possible to avoid > breathing and yet, strangely, breathing is not a stupid activity because > of it. Or, more inline with your thinking, it is possible to avoid > EXIT_FAILURE, which doesn't make EXIT_FAILURE stupid. (Other things make > it that. :) Oh give me a break, that argument makes absolutely no sense at all. While I can see lots of reasons to avoid breaking a standard, why on earth would anyone want to avoid adhering to one? Regards, Peter -- +---------------------------------------------------------------+ | 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/03/01 PST