Re: on goto

Discussion in 'C Programming' started by Dave Harris, May 9, 2010.

  1. Dave Harris

    Dave Harris Guest

    (Daniel T.) wrote (abridged):
    > > I considered submitting a single loop solution as a joke. It
    > > never crossed my mind someone would seriusly propose it!

    >
    > I seriously proposed it. I think it is the best solution for the
    > job (not your code specifically of course, but the idea of a single
    > loop traversing a single container.)


    Yes. It led to simple code, but that was partly because all the
    complexity was hidden behind an iterator. Nathan Baker's version exposes
    some of that complexity, and I think illustrates how hard it is to get it
    right.

    For example, you can't just initialise the iterator's members to 0,0,0
    because data.size() might be 0 and data[0][0][0] may not exist. So you
    need a loop inside the iterator's constructor to find the first iterator
    value that can be dereferenced, and another loop inside the iterator's
    increment operator to find the next one.

    I think. If someone posted actual, correct code, I missed it. Did you try
    implementing the iterator you suggested? Did it still have 3 loops
    really?

    -- Dave Harris, Nottingham, UK.
    Dave Harris, May 9, 2010
    #1
    1. Advertising

  2. Dave Harris

    Seebs Guest

    On 2010-05-10, Nathan Baker <> wrote:
    > Perhaps the words "simple" and "complexity" have different meanings to
    > different people because of their different training and the goals they've
    > been conditioned to target??


    Quite possible. Idioms are much simpler than any analysis of their
    components would suggest.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 10, 2010
    #2
    1. Advertising

  3. Dave Harris

    Seebs Guest

    On 2010-05-10, Richard Heathfield <> wrote:
    > Yes. But, for me, SESE is idiomatic.


    That's not an idiom, that's a policy.

    An idiom is a very specific way of writing a loop, not a general rule
    as to how loops should be written.

    for (i = 0; i < N; ++i)

    is an idiom. SESE is a policy about how code should be written; it's
    not an idiom, because you have to look at the details of the logic for
    every separate loop to figure out how you might do it, and there's
    multiple choices.

    > It is probably fair to say that my advocacy of SESE is a mild (and
    > relatively harmless) over-reaction to those torrid times.


    Yes. But again, I point out that we had someone do a SESE rewrite of
    something, and several people misunderstood the rewrite, while no
    one seems to have had any trouble at all understanding the SEME
    version.

    Simple rules with exceptions are easier for humans to process than
    complicated rules. As long as the people maintaining the code are
    human, there will be a large set of SEME loops which are clearer to
    readers in general than any possible SESE equivalent. ("in general"
    meaning that, if you take an arbitrary random sample of developers,
    you will find that fewer of them misunderstand the SEME loops
    than the SESE ones.)

    There are, of course, a large set of loops where it goes the other way.
    My response to this is to say that I'll use whichever seems to be most
    expressive and clear.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 10, 2010
    #3
  4. Dave Harris

    Phil Carmody Guest

    "Nathan Baker" <> writes:
    > "Dave Harris" <> wrote in message
    > news:...
    >>
    >> Yes. It led to simple code, but that was partly because all the
    >> complexity was hidden behind an iterator. Nathan Baker's version exposes
    >> some of that complexity, and I think illustrates how hard it is to get it
    >> right.
    >>

    >
    > Perhaps the words "simple" and "complexity" have different meanings to
    > different people because of their different training and the goals they've
    > been conditioned to target??
    >
    > Juha's code uses 3 loop constructs, 4 conditionals, and 2 exit points.
    >
    > Mine uses 1 loop construct, 2 conditionals, and 1 exit point.


    Heading up-thread, the most recent code from you I see is:

    """
    while ( data[xInd][yInd][zInd] != value && result != 0)
    {
    ++zInd;
    if (( zInd < data[xInd][yInd].size() ) != true ) { zInd = 0; +
    +yInd};
    if (( yInd < data[xInd].size() ) != true ) { yInd = 0; ++xInd};
    if (( xInd < data.size() ) != true ) { result = 0 };
    }
    """

    Which may have one loop construct, but 9 logical tests - at least 8
    of which are performed on every iteration of the loop. Where you get
    "2 conditionals" from, I don't know.

    Phil

    --
    I find the easiest thing to do is to k/f myself and just troll away
    -- David Melville on r.a.s.f1
    Phil Carmody, May 10, 2010
    #4
  5. Dave Harris

    Nathan Guest

    On May 10, 3:38 am, Phil Carmody <>
    wrote:
    > "Nathan Baker" <> writes:
    > > "Dave Harris" <> wrote in message
    > >news:...

    >
    > >> Yes. It led to simple code, but that was partly because all the
    > >> complexity was hidden behind an iterator. Nathan Baker's version exposes
    > >> some of that complexity, and I think illustrates how hard it is to get it
    > >> right.

    >
    > > Perhaps the words "simple" and "complexity" have different meanings to
    > > different people because of their different training and the goals they've
    > > been conditioned to target??

    >
    > > Juha's code uses 3 loop constructs, 4 conditionals, and 2 exit points.

    >
    > > Mine uses 1 loop construct, 2 conditionals, and 1 exit point.

    >
    > Heading up-thread, the most recent code from you I see is:
    >
    > """
    > while ( data[xInd][yInd][zInd] != value && result != 0)
    > {
    >     ++zInd;
    >     if (( zInd < data[xInd][yInd].size() ) != true ) { zInd = 0; +
    > +yInd};
    >     if (( yInd < data[xInd].size() ) != true ) { yInd = 0; ++xInd};
    >     if (( xInd < data.size() ) != true ) { result = 0 };}
    >
    > """
    >
    > Which may have one loop construct, but 9 logical tests - at least 8
    > of which are performed on every iteration of the loop. Where you get
    > "2 conditionals" from, I don't know.
    >


    Oh Fat, I was talking about what I posted on May 6th in reply to Keith
    Thompson:

    ,---
    xyzMax = data[xInd][yInd].size() + data[xInd].size() + data.size();
    result = 0;
    i = -1;
    while ( i < xyzMax )
    {
    ++i;
    if ( data = value );
    {
    result = &data;
    i = xyzMax;
    }
    }

    return result;
    `---

    Perhaps it did not propagate to all servers?? Anyway, it is buggy and
    Dave is correct about it exposing some of the complexity hidden within
    Daniel's iterator.

    Nathan.
    Nathan, May 10, 2010
    #5
  6. Dave Harris

    Willem Guest

    Richard Heathfield wrote:
    ) Seebs wrote:
    )> On 2010-05-10, Richard Heathfield <> wrote:
    )>> Yes. But, for me, SESE is idiomatic.
    )>
    )> That's not an idiom, that's a policy.
    )
    ) Yes, but it's an idiomatic policy. A high-level idiom, if you like.

    I don't like. The word 'idiom' speaks of 'an expression, word or phrase'.
    So no, SESE cannot possibly be idiomatic by any measure of the word.

    ) I understand the point behind your reply, of course. It's just that I
    ) don't agree with it. (As with many style issues, there is no one right
    ) answer that works for everybody.)

    I'm not seeing any refutations here of the arguments that Seebs presented.
    Perhaps you're not understanding the actual point, but instead thinking of
    a different point that you can dismiss easily. This happens a lot.


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
    Willem, May 10, 2010
    #6
  7. Dave Harris

    Seebs Guest

    On 2010-05-10, Richard Heathfield <> wrote:
    > Seebs wrote:
    >> On 2010-05-10, Richard Heathfield <> wrote:
    >>> Yes. But, for me, SESE is idiomatic.


    >> That's not an idiom, that's a policy.


    > Yes, but it's an idiomatic policy. A high-level idiom, if you like.


    Yes. But high-level idioms don't provide the same chunking benefit that
    literal idioms do. The reason to use idioms is that they convert a large
    number of data into a single datum, allowing the brain to use much less
    short-term memory on the idiomatic part while studying the rest.

    >> An idiom is a very specific way of writing a loop,


    > That definition of "idiom" is far too restrictive. For example, it
    > excludes if((fp = fopen(filename, filemode)) == NULL), which is
    > certainly not a very specific way of writing a loop, and yet it is most
    > definitely idiomatic.


    I did not say every specific way of writing a loop is an idiom.

    An A is a B does not imply that all B are A.

    > I understand the point behind your reply, of course. It's just that I
    > don't agree with it. (As with many style issues, there is no one right
    > answer that works for everybody.)


    But there is, in the case of idioms, a right answer that works enough
    better for a sufficiently large majority of the population that it should
    probably be adopted. The cognitive load of a condition which isn't a
    trivial building block is high enough to massively outweigh, in most cases,
    the cost of considering the possibility that something inside the loop
    terminates the loop.

    In short, I think this would be a much better argument for a language other
    than C. C evolved for multiple exits, and this remains the way of using it
    that the largest number of people will read without errors or mistakes
    introduced by the extra complexity.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 10, 2010
    #7
  8. Dave Harris

    Seebs Guest

    On 2010-05-10, Richard Heathfield <> wrote:
    > Seebs wrote:
    >> Yes. But high-level idioms don't provide the same chunking benefit that
    >> literal idioms do. The reason to use idioms is that they convert a large
    >> number of data into a single datum, allowing the brain to use much less
    >> short-term memory on the idiomatic part while studying the rest.


    > Knowing that the loop has a single exit point gives precisely this
    > advantage.


    No, it doesn't. It's a higher-level cognitive advantage. It certainly
    provides one, but it doesn't provide pure chunking, because chunking only
    seems too work for statically-defined things -- you can chunk a loop
    control that's always the same control, but you can't chunk the general
    category of exit conditions.

    At least, most people can't. :)

    > Mucked-up control flow costs computrons.


    It does, but "this loops over the array" is simple enough to be a win
    anyway in most cases.

    >>>> An idiom is a very specific way of writing a loop,

    >>
    >>> That definition of "idiom" is far too restrictive. For example, it
    >>> excludes if((fp = fopen(filename, filemode)) == NULL), which is
    >>> certainly not a very specific way of writing a loop, and yet it is most
    >>> definitely idiomatic.

    >>
    >> I did not say every specific way of writing a loop is an idiom.

    >
    > I didn't think you did. I thought you said "An idiom is a very specific
    > way of writing a loop". An A is a B.


    .... Ahh! Sorry, I missed a 'not', and was very confused.

    And yes, it was too restrictive; not all idioms are loops. But an idiom
    is nonetheless a very specific and literal construct, not a general pattern
    or rule.

    The cost in computrons of ANY loop condition you have to think about or
    evaluate in any way is much, much, higher than the cost of "this loops
    over the contents of A".

    In general, SESE requires more computrons because it duplicates tests or
    conditions, or adds additional tests or conditions.

    Similarly:

    if (!x)
    return NULL;
    /* use x */

    is easier than:
    if (x) {
    /* use x */
    }

    Any time you add indentation (and thus pending conditionals) or extra tests,
    you cost computrons.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 10, 2010
    #8
  9. On May 11, 12:03 am, Seebs <> wrote:
    > On 2010-05-10, Richard Heathfield <> wrote:
    > > Seebs wrote:
    > >> Yes.  But high-level idioms don't provide the same chunking benefit that
    > >> literal idioms do. > > Knowing that the loop has a single exit point gives precisely this

    > > advantage.

    > No, it doesn't.  It's a higher-level cognitive advantage.  It certainly
    > provides one, but it doesn't provide pure chunking, because ...
    > you can't chunk the general category of exit conditions.
    > .
    > At least, most people can't.  :)
    > > Mucked-up control flow costs computrons.

    > It does, but "this loops over the array" is simple enough to be a win
    > anyway in most cases.
    > [etc.]


    Well at least Heathfield and Seebs agree on *something*:
    We seek human cognitive advantage.

    The specific code being debated, IIRC, does *not* even involve
    goto's (*Please change the subject lines, people*), but is
    rather a trivial search through a 3-D array:
    for ...
    for ...
    for ...
    if ... return;
    In fact the code was so straightforward one might wonder why
    alternatives were even being proposed. I did not search the
    thread rigorously; I noticed one code by Nathan(?) which
    seemed obviously inferior. I gather C++ afficionados are
    proposing a new "access method" for such 3-D arrays (I find
    for...for...for much too easy to understand, especially since
    the full package will probably be doing this *many* places
    needfully, for an a priori unfamiliar method to be useful).
    Mr. Heathfield, IIRC, hasn't actually deigned to post an alternative.
    (Contrary to some beliefs I wrote my favorite goto in a smallish
    fraction of a day; to claim you don't have time to rewrite
    for for for if return ... well... :)

    The thread title is "Goto" but break, inside return, and
    switch fallthrough suffer, to smaller extent, the same sin as
    goto. We read
    On Apr 29, 3:20 pm, Tim Rentsch <> wrote:
    > Keith H Duggar <> writes:
    > > Subsequently I discussed that flame war with one of the worlds
    > > genius compiler writers who confirmed the necessity of the inlining
    > > etc controls explained above. However, he also added that in his
    > > experience it is pointless to argue with the anti-goto mob because
    > > it is a religion that ignores all inconvenient empirical evidence.

    > .
    > Essentially the same thing could be said of the pro-goto mob.


    Wrong. The anti-goto mob claims to prefer code that
    is clearly more complex (is Nathan's the best you have?
    Did you ever post your solution, Mr. H?) in order to avoid the
    inside return (or goto). None of us are "pro-goto" per se; we're
    just asking to *look at all the code and make the best trade-offs*,
    or select the "least of evils." It's usually better to introduce
    1 or 2 boolean variables than to write goto, but what if it's 3
    variables and you still need a break? What if by using switch
    case-fallthrough's you save the need for 5 little functions?
    There is no "universal demerit system" for code complications,
    but to assign inside-return a cost of infinity seems much
    too aggressive.

    Hope this helps,
    James Dow Allen
    James Dow Allen, May 10, 2010
    #9
  10. Dave Harris

    Willem Guest

    Let's take your example to make my point:


    Richard Heathfield wrote:
    ) found = 0;
    ) for(x = 0; !found && x < xlim; x++)
    ) {
    ) for(y = 0; !found && y < ylim; y++)
    ) {
    ) for(z = 0; !found && z < zlim; z++)
    ) {
    ) if(haystack[x][y][z] == needle)
    ) {
    ) point_assign(p, x, y, z);
    ) found = 1;
    ) }
    ) }
    ) }
    ) }
    ) return found;

    The benefit of your code, you say, is that you only need to look at the
    conditional in the for statement, to see when the loop will end, right ?

    If a return in the middle of the loops were used, then you not only have
    to look at the loop conditional, but also inside the body of the loop,
    correct ?

    Now, in your code, it ends when you reach the limit of the range,
    or when this 'found' variable becomes true. But, and here's the point,
    to find out what happens to this 'found' variable, you have to look
    *at the body of the code*. Exactly the same thing you have to do when
    you don't follow SESE. So, in fact, in *both* versions, you have to
    look in the body. So that would make them roughly equivalent.

    But, in the SESE version, you *first* have to look at the loop conditional
    *first*, and then in addition to that, you have to look at the loop body,
    and furthermore, you have to search for some arbitrary variable, instead
    of one of a few well-defined words (return, break, goto, longjmp).

    And, to top it off, any maintenance programmer worth his salt has seen
    loops of the form 'for (i = 0; i < N; i++) {...}', and can tell almost
    instantly that it's running i over the range [0..N), (just like the
    BASIC version FOR i = 0 TO N, as a matter of fact).

    Now, in SESE code, there are a lot of different ways to make it happen.
    One way is to use a boolean flag. Another is to manipulate the loop
    counters. Another is to use a temporary to hold the result and check
    for that, and I'm sure that plenty more versions exist.

    So that, in total, are _three_ reasons why the SESE version is more
    difficult to understand.


    PS: I saw that you acknowledged not having refuted any arguments, so
    feel free to ignore this as well.


    PPS: Yes, that 'PS' is baiting you. I very much dislike it when people
    stop arguing their side with a notion of "we're not going to agree",
    while there are sound, factual arguments on the table.


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
    Willem, May 10, 2010
    #10
  11. Dave Harris

    Seebs Guest

    On 2010-05-10, Richard Heathfield <> wrote:
    > Actually, I think Seebs and I agree on a great deal. This happens to be
    > something about which we mostly disagree, but even then we can find
    > small but significant areas of agreement, if we look hard enough.


    Yes.

    > erroneously reconstruct it:
    >
    > found = 0;
    > for(x = 0; !found && x < xlim; x++)
    > {
    > for(y = 0; !found && y < ylim; y++)
    > {
    > for(z = 0; !found && z < zlim; z++)
    > {
    > if(haystack[x][y][z] == needle)
    > {
    > point_assign(p, x, y, z);
    > found = 1;
    > }
    > }
    > }
    > }
    > return found;


    > Laugh away, sirrah! :)


    Okay, let's compare this with:

    for (x = 0; x < xlim; ++x) {
    for (y = 0; y < ylim; ++y) {
    for (z = 0; z < zlim; ++z) {
    if (haystack[x][y][z] == needle) {
    point_assign(p, x, y, z);
    return 1;
    }
    }
    }
    }
    return 0;

    I consider this much, much, easier to read. It gains even more if we
    use the original's "return &haystack[x][y][z]".

    In this case, I think yours is pretty close, because "!found && " is itself
    a bit of an idiom. However, I find the latter easier to understand because
    it's unambigously "loop over the entire array, doing { if you found a match,
    set something and return 1 }", while for yours, I have to model it cognitively
    as "loop until either something happens or we have covered this whole range,
    doing { loop either until something happens or we have covered this whole
    range, doing { loop either until something happens or we have covered this
    whole range, doing { if you found a match, set something, and set something
    else } } }".

    Because the test conditions aren't part of the standard "loop over array"
    idiom, I have to track both parts of the test condition separately, and doing
    that for three layers of looping chews up six short-term memory slots, and
    the index variables use up three more, leaving me solidly past my short-term
    memory budget without even looking at the inner loop. For the form using
    the pure idiom, I'm only using three slots -- I have x, y, and z as "the
    current indexes in the loop".

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 10, 2010
    #11
  12. Dave Harris

    Phil Carmody Guest

    Seebs <> writes:
    > On 2010-05-10, Richard Heathfield <> wrote:
    >> for(x = 0; !found && x < xlim; x++)


    > for (x = 0; x < xlim; ++x) {


    > Because the test conditions aren't part of the standard "loop over array"
    > idiom, I have to track both parts of the test condition separately, and doing
    > that for three layers of looping chews up six short-term memory slots, and
    > the index variables use up three more, leaving me solidly past my short-term
    > memory budget without even looking at the inner loop. For the form using
    > the pure idiom, I'm only using three slots -- I have x, y, and z as "the
    > current indexes in the loop".


    There's a 4th slot in use. It's
    three trivial loops and one trivial special case
    versus
    three non-trivial loops

    I agree that I view the former as simpler, (but am more likely
    to be a break-user than a return-user).

    Phil
    --
    I find the easiest thing to do is to k/f myself and just troll away
    -- David Melville on r.a.s.f1
    Phil Carmody, May 11, 2010
    #12
  13. Dave Harris

    Phil Carmody Guest

    Richard Heathfield <> writes:
    > Willem wrote:
    >> Let's take your example to make my point:
    >> Richard Heathfield wrote:
    >> ) found = 0;
    >> ) for(x = 0; !found && x < xlim; x++)


    > No, the benefit of SESE is that you know that every loop has a single
    > entry point and a single exit point.


    It can exit after !found fails, or after x < xlim fails.

    Phil
    --
    I find the easiest thing to do is to k/f myself and just troll away
    -- David Melville on r.a.s.f1
    Phil Carmody, May 11, 2010
    #13
  14. Dave Harris

    Seebs Guest

    On 2010-05-11, Richard Heathfield <> wrote:
    > Bait away. My preference for SESE is rooted in some truly appalling SEME
    > code that I've had to maintain in the past.


    Having read posts by Mr. Nilges, why do you persist in using English, when
    it is clearly a language which supports apallingly bad writing?

    Which is to say: The fact that bad code can be written which can be fairly
    described as using multiple exits does not in any way establish that multiple
    exits are at fault. It is quite possible to write deeply illucid code which
    uses single exits. Multiple exits are not the underlying source of that
    problem, any more than C is at fault for all the atrocious C out there.

    C is very much a "here's the gun, here's your foot, do whatever you want"
    language. Sometimes you need this. Similarly, multiple exits certainly
    CAN create bad code... But sometimes that flexibility is needed to create
    the best possible code for expressing something clearly and/or evaluating
    it efficiently. Refusing to use them because someone somewhere used them
    poorly is silly.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 11, 2010
    #14
  15. Dave Harris

    Seebs Guest

    On 2010-05-11, Phil Carmody <> wrote:
    > Seebs <> writes:
    >> Because the test conditions aren't part of the standard "loop over array"
    >> idiom, I have to track both parts of the test condition separately, and doing
    >> that for three layers of looping chews up six short-term memory slots, and
    >> the index variables use up three more, leaving me solidly past my short-term
    >> memory budget without even looking at the inner loop. For the form using
    >> the pure idiom, I'm only using three slots -- I have x, y, and z as "the
    >> current indexes in the loop".


    > There's a 4th slot in use. It's
    > three trivial loops and one trivial special case
    > versus
    > three non-trivial loops


    > I agree that I view the former as simpler, (but am more likely
    > to be a break-user than a return-user).


    I was thinking about what I have to have in mind when I'm looking at the
    contents of the inner loop. The trivial special case *is* the contents
    of the inner loop -- it's no worse in complexity than the "found = 1" or
    similar trait that some SESE advocates have proposed.

    In the case of the "return a pointer to a[x][y][z]" function, I actually
    rather liked using the pointer itself as the test-for-done, although I'm
    not sure whether I should. In general, though, I've been using if (p) long
    enough that a pointer is always comfortable for me as a boolean; either it
    points or it doesn't.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 11, 2010
    #15
  16. On 10 May, 18:36, James Dow Allen <> wrote:
    > On May 11, 12:03 am, Seebs <> wrote:
    > > On 2010-05-10, Richard Heathfield <> wrote:
    > > > Seebs wrote:


    [seebs early exit]
    [heathfield strict Single Exit]


    > Well at least Heathfield and Seebs agree on *something*:
    > We seek human cognitive advantage.
    >
    > The specific code being debated, IIRC, does *not* even involve
    > goto's (*Please change the subject lines, people*), but is
    > rather a trivial search through a 3-D array:
    >      for ...
    >          for ...
    >              for ...
    >                  if ... return;
    > In fact the code was so straightforward one might wonder why
    > alternatives were even being proposed.


    too right...


    > I did not search the
    > thread rigorously; I noticed one code by Nathan(?) which
    > seemed obviously inferior.  I gather C++ afficionados are
    > proposing a new "access method" for such 3-D arrays (I find
    > for...for...for much too easy to understand, especially since
    > the full package will probably be doing this *many* places
    > needfully, for an a priori unfamiliar method to be useful).
    > Mr. Heathfield, IIRC, hasn't actually deigned to post an alternative.


    I think he proposed

    for (loop_incomplete OR not_found)
    for (loop_incomplete OR not_found)
    for (loop_incomplete OR not_found)
    if ... found <- T

    that is an extra boolean (and some extra testing)

    > (Contrary to some beliefs I wrote my favorite goto in a smallish
    > fraction of a day; to claim you don't have time to rewrite
    > for for for if return ... well...  :)
    >
    > The thread title is "Goto" but break, inside return, and
    > switch fallthrough suffer, to smaller extent, the same sin as
    > goto.  


    no, not really. Early exit isn't goto.


    > We read
    > On Apr 29, 3:20 pm, Tim Rentsch <> wrote:
    > > Keith H Duggar <> writes:

    >
    > > > Subsequently I discussed that flame war with one of the worlds
    > > > genius compiler writers who confirmed the necessity of the inlining
    > > > etc controls explained above. However, he also added that in his
    > > > experience it is pointless to argue with the anti-goto mob because
    > > > it is a religion that ignores all inconvenient empirical evidence.

    > > .
    > > Essentially the same thing could be said of the pro-goto mob.


    I rather be referred to as the Early Exit Mob


    > Wrong.  The anti-goto mob claims to prefer code that
    > is clearly more complex


    well they don't accept your premise. Though I think abusing C's overly
    complicated for-loop constuct is well on the road to ruin. {turing
    over another rock and finding a can of worms]


    > (is Nathan's the best you have?
    > Did you ever post your solution, Mr. H?) in order to avoid the
    > inside return (or goto).  None of us are "pro-goto" per se; we're
    > just asking to *look at all the code and make the best trade-offs*,


    I think everyone's claimign to be doing that. Unless someone wants to
    pay the cognitive scientists to do their stuff we're stuck with "well,
    MY way is OBVIOUSLY better" reiterated.

    > or select the "least of evils."  It's usually better to introduce
    > 1 or 2 boolean variables than to write goto,


    or return or break?

    > but what if it's 3
    > variables and you still need a break?  What if by using switch
    > case-fallthrough's you save the need for 5 little functions?


    ah, sometimes the 5 little functions are good. Fowler "Refactoring"

    > There is no "universal demerit system" for code complications,
    > but to assign inside-return a cost of infinity seems much
    > too aggressive.


    yes. That's nearly a keeper


    --
    But ye have set at nought all my counsel, and would none of my
    reproof:
    I also will laugh at your calamity; I will mock when your fear
    cometh;
    [Proverbs 1:25]
    Nick Keighley, May 11, 2010
    #16
  17. On 11 May, 06:26, Richard Heathfield <> wrote:

    > My preference for SESE is rooted in some truly appalling SEME
    > code that I've had to maintain in the past.


    but MEME is even *more* fun. But that needs a truly awesome assemly
    programmer.
    Nick Keighley, May 11, 2010
    #17
  18. on complexity [Was: on goto]

    On 10 May, 19:05, Richard Heathfield <> wrote:
    > James Dow Allen wrote:
    >
    > <snip>
    >
    > > Well at least Heathfield and Seebs agree on *something*:
    > > We seek human cognitive advantage.

    >
    > Actually, I think Seebs and I agree on a great deal. This happens to be
    > something about which we mostly disagree, but even then we can find
    > small but significant areas of agreement, if we look hard enough.
    >
    > <snip>
    >
    > > Mr. Heathfield, IIRC, hasn't actually deigned to post an alternative.

    >
    > I'm reasonably sure I did deign to post an alternative. But I may not
    > have done. I may merely have posted an alternative.
    >
    > To save me finding it, however, I'll very quickly and no doubt
    > erroneously reconstruct it:
    >
    > found = 0;
    > for(x = 0; !found && x < xlim; x++)
    > {
    >    for(y = 0; !found && y < ylim; y++)
    >    {
    >      for(z = 0; !found && z < zlim; z++)
    >      {
    >        if(haystack[x][y][z] == needle)
    >        {
    >          point_assign(p, x, y, z);
    >          found = 1;
    >        }
    >      }
    >    }}
    >
    > return found;
    >
    > Laugh away, sirrah! :)
    >
    > <snip>
    >
    > > Hope this helps,

    >
    > Yup. Style arguments are always fun.


    both versions of the algorithm gave the same complexity measurement in
    a tool I have. They both rated 5 for cyclometric complexity.
    Nick Keighley, May 11, 2010
    #18
  19. Re: on complexity [Was: on goto]

    On 11 May, 09:29, Richard Heathfield <> wrote:
    > Nick Keighley wrote:


    > > both versions of the algorithm gave the same complexity measurement in
    > > a tool I have. They both rated 5 for cyclometric complexity.

    >
    > McCabe, by any chance?


    it just says "cyclometric". From the tool makers website:-

    "Cyclomatic -- Cyclomatic complexity as per the original NIST paper on
    the subject. Edges - Nodes + Connected Components."

    > If so, how does the visual rep of the code come out? Which *looks* simpler?


    the early exit version looks simpler on a graph (honestly!). But the
    EE for-loops get graphed as single nodes whilst SE for-loops warrent
    extra edges on the graph. I'm slightly surprised they gave the measure
    considering the graphs look so different.
    Nick Keighley, May 11, 2010
    #19
  20. Re: on complexity [Was: on goto]

    On 11 May, 10:07, Richard Heathfield <> wrote:
    > Nick Keighley wrote:
    > > On 11 May, 09:29, Richard Heathfield <> wrote:
    > >> Nick Keighley wrote:

    >
    > >>> both versions of the algorithm gave the same complexity measurement in
    > >>> a tool I have. They both rated 5 for cyclometric complexity.

    >
    > >> McCabe, by any chance?

    >
    > > it just says "cyclometric".

    >
    > I meant the tool maker's software.


    ah, sorry I thought you were asking "which cyclometric complexity"

    > If you're not using McCabe, I guess
    > you're using "Understand"?


    yup


    > > From the tool makers website:-

    >
    > > "Cyclomatic -- Cyclomatic complexity as per the original NIST paper on
    > > the subject. Edges - Nodes + Connected Components."

    >
    > >> If so, how does the visual rep of the code come out? Which *looks* simpler?

    >
    > > the early exit version looks simpler on a graph (honestly!).

    >
    > Any chance of a PNG (or BMP) of each? If you don't want to use your own
    > Web space for this, you could perhaps email them to me, and I'll
    > cheerfully find some scratch space for them.


    PDF? (not my choice but Understand's). Haven't got access to my
    webspace at present so I can email them. Is PDF ok or would you like
    something else (I'll only alt-print screen them)
    Nick Keighley, May 11, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. youngsun park
    Replies:
    2
    Views:
    610
    David Pursley
    Nov 18, 2003
  2. Skybuck Flying

    VHDL Goto statement ?

    Skybuck Flying, Aug 8, 2005, in forum: VHDL
    Replies:
    9
    Views:
    6,086
    ajahn
    Aug 26, 2005
  3. Skybuck Flying

    Re: VHDL Goto statement ?

    Skybuck Flying, Aug 8, 2005, in forum: VHDL
    Replies:
    0
    Views:
    725
    Skybuck Flying
    Aug 8, 2005
  4. Flip
    Replies:
    6
    Views:
    6,656
    Jeff Dillon
    Nov 18, 2004
  5. Flip
    Replies:
    1
    Views:
    627
    Brock Allen
    Apr 14, 2005
Loading...

Share This Page