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: fac41,9a0ff0bffdf63657
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,4b06f8f15f01a568
X-Google-Attributes: gid103376,public
X-Google-Thread: f43e6,9a0ff0bffdf63657
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 1108a1,9a0ff0bffdf63657
X-Google-Attributes: gid1108a1,public
From: jtc@dimensional.com (Jim Cochrane)
Subject: Re: Software landmines (loops)
Date: 1998/09/02
Message-ID: <6sil52$g3a@flatland.dimensional.com>#1/1
X-Deja-AN: 387025784
References: <slrn6sopmg.4fg.jdege@jdege.visi.com> <35f51e53.48044143@
 <m3af4mq7f4 <6shhg4$llp$1@hirame.wwa.com>
Organization: Dimensional Communications
NNTP-Posting-Date: Tue, 01 Sep 1998 23:30:21 MDT
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-09-02T00:00:00+00:00
List-Id: <comp.lang.ada>

In addition to what Robert points out, the potential problem can easily be
eliminated by changing "equal == true" to simply "equal".  [Or you can
simply switch to Eiffel where the equivalent typo "equal = true" -> "equal
:= true" would not compile. :-)]

I think the problem here is not the proposed algorithm, but is simply a C++
syntax anomoly that causes a potential hazard, which can occur within any
algorithm implementation.

[Besides, why would anyone want to change a piece of code like this that is
already written?  You do have a rule in your org., don't you, that
disallows copying and pasting? :-)]

In article <6shhg4$llp$1@hirame.wwa.com>,
Robert Martin <rmartin@oma.com> wrote:
>
>Chris Brand wrote in message <35EC3440.9FA81BF1@west.raytheon.com>...
>>Robert Martin wrote:
>>>
>>> bool operator==(Stack& l, Stack& r)
>>> {
>>>   bool equal = true;
>>>   for (int index = 1; index < l.top() && equal == true; index++)
>>>   {
>>>     if (l[index] != r[index])
>>>       equal = false;
>>>   }
>>>   return equal;
>>> }
>>>
>>> If this is more complex (something that is arguable) it is not *much*
>more
>>> complex.  On the other hand, it is easier to maintain.
>>
>>It is open to (maintenance) errors such as
>>   for (int index = 1; index < l.top() && equal = true; index++)
>>which the multiple-return version isn't, so the "easier to maintain"
>>argument is far from clear-cut.
>
>
>I think *all* structures are vulnerable to typos.  The code above is no more
>vulnerable than any other code is.
>
>
>Robert C. Martin    | Design Consulting   | Training courses offered:
>Object Mentor       | rmartin@oma.com     |   Object Oriented Design
>14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
>Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
>
>"One of the great commandments of science is:
>    'Mistrust arguments from authority.'" -- Carl Sagan
>
>
>


-- 
Jim Cochrane
jtc@dimensional.com