From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: "Dan Higdon" Subject: Re: Software landmines (was: Why C++ is successful) Date: 1998/08/20 Message-ID: #1/1 X-Deja-AN: 383124315 References: <6qfhri$gs7$1@nnrp1.dejanews.com> <35cb8058.645630787@news.ne.mediaone.net> <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Trace: news.giganews.com 903648047 207.207.44.53 (Thu, 20 Aug 1998 16:20:47 CDT) NNTP-Posting-Date: Thu, 20 Aug 1998 16:20:47 CDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-08-20T00:00:00+00:00 List-Id: adam@irvine.com wrote in message <6rfra4$rul$1@nnrp1.dejanews.com>... >Well, I might have used GOTO if I had to do it over again. My early >training taught me to avoid them, and this avoidance has become kind >of ingrained. I still probably wouldn't use "continue", however. Then you probably wouldn't object to something like (pseudocode, as I'm not much of an Eiffel programmer): loop if not then -- whole bunch of stuff end if end loop Instead? That at least still only has you making the decision to branch once, instead of once when you set the flag and once when you decide what you meant earlier. I'll agree on the 'continue' avoidance, although I've found that constructs like that can make code a little cleaner if there is a whole lot of code in the "else" case. (Probably putting that code into a separate function would make it even more clear. :-) >However: > >#1: Adding a flag in the manner I've described does not change the >algorithm, it merely changes the way the flow of control is expressed. >Unless you adopt a definition of "algorithm" that is so strict as to >be useless except to an academic. You're checking the exit condition twice instead of once. That's a little like saying that the 'k' term of a "Big O" analysis doesn't matter, IMHO. It's not the meat of the algorithm, but it's definitely a detail. >#2: How important efficiency is depends on what you're writing. If >you're working on time-critical code, it's very important, but if >you're working on an application where most of the program's time will >be spent waiting for the user to type in some input, a few hundred >microseconds isn't anything to worry about. I probably shouldn't have come from a code efficiency standpoint - my real objection is related to boolean flag usage. If your algorithm demands that you be able to remind yourself later about a condition, then by all means. As this relates to the topic: I think that the use of boolean flags strictly for local flow control is a software landmine. An unappreciated one (because so much Pascal has been taught, and that's the only way to get Pascal to do some things), but a landmine none the less. >#3: A good optimizing compiler wouldn't do a compare/branch. It might I'm too suspicious of tool quality to rely on good compilers too much. >#4: Programmers don't always get to choose which language they use. Too true - I have to use C++. Hence my fear of tool quality. :-) >#5: In this thread, we're arguing about readability and >maintainability. If you have a situation where every nanosecond is >critical, fine, but most of us are willing to give up a few >nanoseconds in order to save time debugging and maintaining programs. Yes, I want to get back on topic as well - I agree that nanosecond timing considerations and readable code don't always coexist peacfully. Sadly, it looks like we're getting into the subjective side of what is readable and maintainable. I find flags (local vars - not object data slots) distracting. Obviously you do not. I guess we'll have to agree to disagree? >There are lots of language constructs that aren't really "needed". >And there are plenty of cases where an individual programmer, or a >programming department, adopts a policy of avoiding a particular >construct, which is fine as long as the prohibition isn't 100% I'll agree with that - we don't use exceptions (time sensitivity issues) or templates (bad compiler support) in our C++ code usually, but sometimes a template is the best way to do something. (But don't get me started on the STL - one of the most compelling reasons to switch away from C++ yet, IMHO.) >absolute. A long time ago, I programmed in COBOL, and most of the >programmers around me agreed that the ALTER statement was just a bad >idea and shouldn't be used. I'll bet few would disagree with such a >policy. I've not had the pleasure(?) of programming in COBOL - FORTRAN was my teething ring. But I suspect ALTER is about as much fun to maintain as an arithmatic IF statement. :-) ---------------------------------------- hdan@charybdis.com "Throwing fire at the sun"