break considered harmful 
Author Message
 break considered harmful

Quote:

> The observation that avoiding break, continue, or goto in many cases pretty
> much requires the use of an extra flag variable, is AFAIK a fact and
> thus not subject to "mileage variations".  The mileage variations come into
> play when deciding whether that extra variable and the extra tests for it
> are less ugly than violating Structured Programming.  Personally, MMdoesV,
> and I freely choose from both styles as the mood strikes me.

In C, the use of break in other than switch statements is
considered harmful to the clear understanding and maintenance of
the code.  goto can be much more understandable.  Consider the
following fragment:

    while (condition) {
       /* lots of code */
       if (whatever) break;
       /* lots more code */
    }

When control reaches this point (loop exit), the programmer should
want to know what conditions apply.  His natural inclination is to
examine "condition".  However, he is *WRONG*.

Now consider the following variant:

    while (condition) {
       /* lots of code */
       if (whatever) goto label;
       /* lots more code */
    }
label:

The poor pitiable programmer now has a label staring him in the
face at loop exit.  AHA, he screams in soothing dulcet tones, 'how
did I get here?'.  He does a text search for label, and lo and
behold, the test of "whatever" pops up.  Now he knows that either
condition is false or whatever is true at that point.

In other words, he can elicit the function of a block without
detailed reading of it.  He can probably now write down a loop
invariant that has some hope of being accurate.  Notice that no
confusing flag variables have been created.

Also consider the following:

   while (cond1) {
      /* mass1 */
      /* mass2 */
      if (whatever) break;
      /* mass3 */
      /* mass4 */
   }

and someone decides that mass2 and mass3 should be repeated, so he
converts to:

   while (cond1) {
      /* mass1 */
      do {
         /* mass2 */
         if (whatever) break;
         /* mass3 */
      } while (cond2);
      /* mass4 */
   }

and for some reason it doesn't work!!.  However, if the break had
been replaced by a goto as above, with the appropriate exit label,
the modification would have been correct (or at least more likely
to be correct).  Again, there is a flag staring that overloaded
and confused maintenance programmer in the face.

There is a major difference between a loop and a loop and a half.

--

   Available for consulting/temporary embedded and systems.
   (Remove "XXXX" from reply address. yahoo works unmodified)



Tue, 29 Jun 2004 02:17:36 GMT  
 break considered harmful


Quote:

> > The observation that avoiding break, continue, or goto in many cases
pretty
> > much requires the use of an extra flag variable, is AFAIK a fact and
> > thus not subject to "mileage variations".  The mileage variations come
into
> > play when deciding whether that extra variable and the extra tests for
it
> > are less ugly than violating Structured Programming.  Personally,
MMdoesV,
> > and I freely choose from both styles as the mood strikes me.

> In C, the use of break in other than switch statements is
> considered harmful to the clear understanding and maintenance of
> the code.  goto can be much more understandable.  Consider the
> following fragment:

>     while (condition) {
>        /* lots of code */
>        if (whatever) break;
>        /* lots more code */
>     }

> When control reaches this point (loop exit), the programmer should
> want to know what conditions apply.  His natural inclination is to
> examine "condition".  However, he is *WRONG*.

> Now consider the following variant:

>     while (condition) {
>        /* lots of code */
>        if (whatever) goto label;
>        /* lots more code */
>     }
> label:
>> The execution is on this line (right below label:). Where did I came

from? End of while block or goto?

<snip>

Quote:

> --

>    Available for consulting/temporary embedded and systems.
>    (Remove "XXXX" from reply address. yahoo works unmodified)


Dan


Tue, 29 Jun 2004 02:25:29 GMT  
 break considered harmful

Quote:

> In C, the use of break in other than switch statements is
> considered harmful to the clear understanding and maintenance of

            ^ by some programmers
Quote:
> the code. [...]



Tue, 29 Jun 2004 02:37:45 GMT  
 break considered harmful

Quote:

> In C, the use of break in other than switch statements is
> considered harmful to the clear understanding and maintenance of
> the code.  goto can be much more understandable.

And, both should be avoided...at least I am not certain where they might
be useful, certainly not in the example provided.

To use and modify your example, a better way to write it might be:

    while (condition)
    {
       /* lots of code */

       if ( !whatever )
       {
         /* lots more code */
       }
       else
         /* make the condition false */
    }

--
== Eric Gorr ===== http://www.*-*-*.com/ :9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like {*filter*}, are the last refuge of the incompetent... ===



Tue, 29 Jun 2004 04:05:22 GMT  
 break considered harmful

Quote:


>> The observation that avoiding break, continue, or goto in many cases pretty
>> much requires the use of an extra flag variable, is AFAIK a fact and
>> thus not subject to "mileage variations".  The mileage variations come into
>> play when deciding whether that extra variable and the extra tests for it
>> are less ugly than violating Structured Programming.  Personally, MMdoesV,
>> and I freely choose from both styles as the mood strikes me.

>In C, the use of break in other than switch statements is
>considered harmful to the clear understanding and maintenance of
>the code.

That is your opinion.  It's meaningless to say that ``In C something
is considered harmful''. When something is considered, there is someone
who is considering it. And that someone is not ``in'' C.  That someone
is in the world, which has C in it, and that someone is just forming
his or her opinion. If every C programmer has the same opinion about
some matter regarding C, then it can be said that the opinion generally
holds in the C culture. This is not true of your opinion about the
break statement.

Quote:
> goto can be much more understandable.  Consider the
>following fragment:

>    while (condition) {
>       /* lots of code */
>       if (whatever) break;
>       /* lots more code */
>    }

>When control reaches this point (loop exit), the programmer should
>want to know what conditions apply.  His natural inclination is to
>examine "condition".  However, he is *WRONG*.

>Now consider the following variant:

>    while (condition) {
>       /* lots of code */
>       if (whatever) goto label;
>       /* lots more code */
>    }
>label:

Note that a label requires a statement.

Quote:
>The poor pitiable programmer now has a label staring him in the
>face at loop exit.  AHA, he screams in soothing dulcet tones, 'how
>did I get here?'.  He does a text search for label, and lo and
>behold, the test of "whatever" pops up.

Wrong answer. You can get there due to the goto, or due to the loop
guard condition being false.

If you use the appropriate automatic control construct, namely break,
and do not use any goto, then you know that the control can reach that
point after the loop *only* because of the loop guard failing or because
of a break statement in the loop.

With the goto label in place, control can reach that point from anywhere
in the function.

You seem to be arguing against control structures in general: the idea
that there can be implicit control transfers arranged through an
abstraction rather than explicitly.

If you hold a position against structured control, that position
places you in an eccentric minority.

  Now he knows that either

Quote:
>condition is false or whatever is true at that point.

>In other words, he can elicit the function of a block without
>detailed reading of it.  He can probably now write down a loop
>invariant that has some hope of being accurate.

Not without verifying that there is no other transfer of control to
the label. So now a broader chunk of the program has to be considered;
the localization of control provided by the control structure has been
compromised.


Tue, 29 Jun 2004 04:25:37 GMT  
 break considered harmful

Quote:

> In C, the use of break in other than switch statements is
> considered harmful to the clear understanding and maintenance of
> the code.

It really is a matter of opinion.  I programmer who wants to make
his/her code clear may choose to use any style as is appropriate.
Sometimes the use of break really obscures the purpose of the code - at
other times it seems to make the purpose of the code much clearer.  It
is part of the art of programming and communication to decide when
either is appropriate, and it really is a matter of judgement, because
two experts might disagree.

Quote:
> When control reaches this point (loop exit), the programmer should
> want to know what conditions apply.  His natural inclination is to
> examine "condition".  However, he is *WRONG*.

> Now consider the following variant:

>     while (condition) {
>        /* lots of code */
>        if (whatever) goto label;
>        /* lots more code */
>     }
> label:

> The poor pitiable programmer now has a label staring him in the
> face at loop exit.  AHA, he screams in soothing dulcet tones, 'how
> did I get here?'.  He does a text search for label, and lo and
> behold, the test of "whatever" pops up.  Now he knows that either
> condition is false or whatever is true at that point.

I myself use labels and goto's for error or exit or retry conditions.
So I might have code that looks like

  do_something;
  if (bad_thing) goto error;
  do_something_else;
  if (another_bad_thing) goto error;
  ....
  ....
  ....

  error:
  process_error;

As you say the reader of the code is not too sure how he/she got to the
label "error".  But really, it doesn't matter.  All he/she needs to know
is that they got there because there was an error.

--
Stephen Montgomery-Smith

http://www.math.missouri.edu/~stephen



Tue, 29 Jun 2004 05:22:35 GMT  
 break considered harmful

Quote:

> In C, the use of break in other than switch statements is
> considered harmful to the clear understanding and maintenance of
> the code.  goto can be much more understandable.  Consider the
> following fragment:

>     while (condition) {
>        /* lots of code */
>        if (whatever) break;
>        /* lots more code */
>     }

I would contend that the bigger readability problems with this
snippet are the two "lots of code" blocks.  In fact, you probably
would not argue that this code is difficult to maintain if the
two comments were each replaced by one or two lines of code.

I would much prefer if "lots of code" was replaced with a function
call.

Quote:
> When control reaches this point (loop exit), the programmer should
> want to know what conditions apply.  His natural inclination is to
> examine "condition".  However, he is *WRONG*.

> Now consider the following variant:

>     while (condition) {
>        /* lots of code */
>        if (whatever) goto label;
>        /* lots more code */
>     }
> label:

> The poor pitiable programmer now has a label staring him in the
> face at loop exit.  AHA, he screams in soothing dulcet tones, 'how
> did I get here?'.  He does a text search for label, and lo and
> behold, the test of "whatever" pops up.  Now he knows that either
> condition is false or whatever is true at that point.

Now consider a context-sensitive text editor that can display the
keyword "break" in a different color or font than other keywords,
along with a moderately-sized while loop.

Quote:
> In other words, he can elicit the function of a block without
> detailed reading of it.  He can probably now write down a loop
> invariant that has some hope of being accurate.

Only if the reader is *sure* that the loop is only exited via a
goto, and not a combination of gotos and breaks!  If you're not
sure, you'll still have to read the code carefully!

- Show quoted text -

Quote:
> Notice that no
> confusing flag variables have been created.

> Also consider the following:

>    while (cond1) {
>       /* mass1 */
>       /* mass2 */
>       if (whatever) break;
>       /* mass3 */
>       /* mass4 */
>    }

> and someone decides that mass2 and mass3 should be repeated, so he
> converts to:

>    while (cond1) {
>       /* mass1 */
>       do {
>          /* mass2 */
>          if (whatever) break;
>          /* mass3 */
>       } while (cond2);
>       /* mass4 */
>    }

> and for some reason it doesn't work!!.  However, if the break had
> been replaced by a goto as above, with the appropriate exit label,
> the modification would have been correct (or at least more likely
> to be correct).  Again, there is a flag staring that overloaded
> and confused maintenance programmer in the face.

When you say "more likely to be correct", you're talking about a
programmer who casually changes the nesting level of code without
reading it.  I don't think this programmer accidentally getting it
right this time is necessarily a good thing.

- Show quoted text -

Quote:
> There is a major difference between a loop and a loop and a half.



Tue, 29 Jun 2004 08:58:51 GMT  
 break considered harmful
On Thu, 10 Jan 2002 18:17:36 GMT,


| In C, the use of break in other than switch statements is
| considered harmful to the clear understanding and maintenance of
| the code.

Consider these variants:

1) with break
for (i = 0; i < N; i++) {
    /* ... */
    if (condition) break;
    /* ... */

Quote:
}

if (i == N) {
    /* we now know that condition didn't stop the loop

Quote:
}

2) "fully structured"
int stop = 0;
for (i = 0; i < N && !stop; i++) {
    /* ... */
    if (condition) {
        stop = 1;
    } else {
        /* ... */
    }

Quote:
}

if (stop) {
   /* same here */

Quote:
}

Both variants have their merits, and I use both. For longer
(text-wise) loops, 2) is sometimes preferable.

--Daniel

--
"The obvious mathematical breakthrough would be development of an easy
 way to factor large prime numbers."   -- Bill Gates, "The Road Ahead"



Tue, 29 Jun 2004 18:54:15 GMT  
 break considered harmful

Quote:

> Also consider the following:

>    while (cond1) {
>       /* mass1 */
>       /* mass2 */
>       if (whatever) break;
>       /* mass3 */
>       /* mass4 */
>    }

> and someone decides that mass2 and mass3 should be repeated, so he
> converts to:

>    while (cond1) {
>       /* mass1 */
>       do {
>          /* mass2 */
>          if (whatever) break;
>          /* mass3 */
>       } while (cond2);
>       /* mass4 */
>    }

> and for some reason it doesn't work!!.  However, if the break had
> been replaced by a goto as above, with the appropriate exit label,
> the modification would have been correct (or at least more likely
> to be correct).  Again, there is a flag staring that overloaded
> and confused maintenance programmer in the face.

Which is why C should get a leveled break. That way, you could have done
this:

  while (cond1) {
    /* mass1 */
    do {
      /* mass2 */
      if (whatever) break 2;
      /* mass3 */
    } while (cond2);
    /* mass4 */
  }

and broken cleanly out of both loops without using the dreaded goto.
Note the advantage this has for clarity: whereas when you encounter the
goto, you could jump anywhere, and thus have to search for the label,
with a leveled break, you know for certain that there is only one place
you can end up: just beyond the second enclosing loop.
Of course, having done this, the Committee should also introduce a
leveled continue, so you could analogously do something like this:

  while (cond1) {
    /* mass1 */
    do {
      /* mass2 */
      if (whatever1) break 2;
      if (whatever2) continue 2;
      /* mass3 */
    } while (cond2);
    /* mass4 */
  }

allowing the programmer perfect control over the program flow, and
making the coding of various input processing jobs, in particular those
in which some records need to be processed only partially but all
records need at least to be looked at, a whole lot easier.

Finally, for completeness, we should introduce a leveled return. Who of
us has never written a function, which calls other functions, only to
have one of the sub-functions to fail in some way, necessitating a
return from the sub-function, with this failed return requiring {*filter*}
of the calling function in turn, which could call for return from yet
another function? For example, something like this:

  void function2(int &x)
  {
    /* blabla */
    if (something) return;
    /* blabla */
  }

  void function1(int y)
  {
    int i;

    for (int n=1; n<y; n++) {
      i=n;
      function2(&i);
      if (!i) return;
      /* blablabla */
    }
    return;
  }

If only we had a leveled return, we could simplify this to the
following:

  void function2(int &x)
  {
    /* blabla */
    if (something) return 2;
    /* blabla */
  }

  void function1(int y)
  {
    int i;

    for (int n=1; n<y; n++) {
      i=n;
      function2(&i);
      /* blablabla */
    }
    return;
  }

Of course, this does clash with the existing use of return to return a
value from a function. However, we coudl take a leaf out of Pascal's
book, and use the unadorned name of the function, without parameter
list, to signify the return value, like this:

  void function2(int &x)
  {
    /* blabla */
    if (something) { function1=0; return 2; }
    /* blabla */
  }

  int function1(int y)
  {
    int i;

    for (int n=1; n<y; n++) {
      i=n;
      function2(&i);
      /* blablabla */
    }
    function1=i;
    return;
  }

This way, we can even (as illustrated) return a value for a calling
function from within a called function, allowing for far greater power
of expression than current C.

It is clear to me that this is the way to go. Not only will it allow us
to get rid of all the uses one could think of for that abhorred goto,
but in doing so, we will be getting a language that allows us to write
our algorithms more clearly, more concisely, and more easily.

Richard



Tue, 29 Jun 2004 22:07:16 GMT  
 break considered harmful

Quote:



> > In C, the use of break in other than switch statements is
> > considered harmful to the clear understanding and maintenance of
> > the code.  goto can be much more understandable.  Consider the
> > following fragment:

> >     while (condition) {
> >        /* lots of code */
> >        if (whatever) break;
> >        /* lots more code */
> >     }

[snip]

Quote:
> Only if the reader is *sure* that the loop is only exited via a
> goto, and not a combination of gotos and breaks!  If you're not
> sure, you'll still have to read the code carefully!

I "get" the idea of writing code in such a way
so as to facilitate it's modification, but at some point,
the code modifier has to pay attention to what he's doing.

A while ago, somebody, I think it was Joona I Palaste, was looking
for an argument to counter his coworker's policy
of casting the return value from malloc.
I don't recall the exact justification for the cast,
but I remember thinking that at the time, it sounded a lot like
"Suppose you want to modify the code
without paying attention to what you're doing ..."

Quote:
> When you say "more likely to be correct", you're talking about a
> programmer who casually changes the nesting level of code without
> reading it.  I don't think this programmer accidentally getting it
> right this time is necessarily a good thing.

I hate when I test code before posting,
and the Undefined Behavior that it exhibits on my machine,
coincides with what I had intended when I didn't know I was coding UB.

Quote:
> > There is a major difference between a loop and a loop and a half.

... but two half loops, join well, with a break.

The following while loop, consists of two equal halfs.
Each half of the while loop consists of:
1   a conditional expression, to end the loop
2   a double assignment
3   a do loop

    while(base != next){
        middle = last = next;
        do{
            if(Compare(middle, middle - size) < 0){
                memcpy(swap, middle, size);
                memcpy(middle, middle - size, size);
                memcpy(middle - size, swap, size);
                next = middle;
            }
            middle -= size;
        }while(middle != base);
        if(last == next){
            break;
        }
        middle = base = next;
        do{
            if(Compare(middle, middle + size) > 0){
                memcpy(swap, middle, size);
                memcpy(middle, middle + size, size);
                memcpy(middle + size, swap, size);
                next = middle;
            }
            middle += size;
        }while(middle != last);
    }

The while loop could have been written this way:
(the first time I wrote it, it *was* this way)

    while(last != next){
        middle = base = next;
        do{
            if(Compare(middle, middle + size) > 0){
                memcpy(swap, middle, size);
                memcpy(middle, middle + size, size);
                memcpy(middle + size, swap, size);
                next = middle;
            }
            middle += size;
        }while(middle != last);
        if(base == next){
            break;
        }
        middle = last = next;
        do{
            if(Compare(middle, middle - size) < 0){
                memcpy(swap, middle, size);
                memcpy(middle, middle - size, size);
                memcpy(middle - size, swap, size);
                next = middle;
            }
            middle -= size;
        }while(middle != base);      
    }

--
 pete



Tue, 29 Jun 2004 23:16:31 GMT  
 break considered harmful

Quote:


> > The observation that avoiding break, continue, or goto in many cases pretty
> > much requires the use of an extra flag variable, is AFAIK a fact and
> > thus not subject to "mileage variations".  The mileage variations come into
> > play when deciding whether that extra variable and the extra tests for it
> > are less ugly than violating Structured Programming.  Personally, MMdoesV,
> > and I freely choose from both styles as the mood strikes me.

> In C, the use of break in other than switch statements is
> considered harmful to the clear understanding and maintenance of
> the code.  goto can be much more understandable.  Consider the
> following fragment:

>     while (condition) {
>        /* lots of code */
>        if (whatever) break;
>        /* lots more code */
>     }

> When control reaches this point (loop exit), the programmer should
> want to know what conditions apply.  His natural inclination is to
> examine "condition".  However, he is *WRONG*.

> Now consider the following variant:

>     while (condition) {
>        /* lots of code */
>        if (whatever) goto label;
>        /* lots more code */
>     }
> label:

> The poor pitiable programmer now has a label staring him in the
> face at loop exit.  AHA, he screams in soothing dulcet tones, 'how
> did I get here?'.  He does a text search for label, and lo and
> behold, the test of "whatever" pops up.  Now he knows that either
> condition is false or whatever is true at that point.

> In other words, he can elicit the function of a block without
> detailed reading of it.  He can probably now write down a loop
> invariant that has some hope of being accurate.  Notice that no
> confusing flag variables have been created.

> Also consider the following:

>    while (cond1) {
>       /* mass1 */
>       /* mass2 */
>       if (whatever) break;
>       /* mass3 */
>       /* mass4 */
>    }

> and someone decides that mass2 and mass3 should be repeated, so he
> converts to:

>    while (cond1) {
>       /* mass1 */
>       do {
>          /* mass2 */
>          if (whatever) break;
>          /* mass3 */
>       } while (cond2);
>       /* mass4 */
>    }

> and for some reason it doesn't work!!.  However, if the break had
> been replaced by a goto as above, with the appropriate exit label,
> the modification would have been correct (or at least more likely
> to be correct).  Again, there is a flag staring that overloaded
> and confused maintenance programmer in the face.

> There is a major difference between a loop and a loop and a half.

As expected, people have been objecting to the goto uses above.
At least I have provoked some thought.

I *AM NOT* recommending unrestricted willy-nilly use of goto.  In
fact, it would be quite acceptable to restrict a label to be
accessed only from one goto.  In some cases that would require
siting multiple labels at the same point - we do this already,
look at the structure of a switch statement.  With the language as
it is all that is required is to apply some self discipline to get
the same effect.

Goofs happen during code revision.  Programmers are not
perfect[1].  My attitude is to look at the structure of a goof,
and see what sort of practices would reduce its likelihood in
similar cases.  goto is available, and helpful *IF USED WISELY*.

There are even cases when a goto can significantly improve code
efficiency.  Donald Knuth presented some telling examples a few
years ago.  I don't have the references handy.  But this is not
about that, it is about improved clarity and maintainability.  One
of the ways of avoiding new errors is to make minimum changes.

[1] I made a mistake once.

--

   Available for consulting/temporary embedded and systems.
   (Remove "XXXX" from reply address. yahoo works unmodified)



Wed, 30 Jun 2004 05:34:51 GMT  
 break considered harmful

Quote:

> Which is why C should get a leveled break.

ROFL!  (That WAS satire, wasn't it??  If not, oops, sorry! :-)

--

|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Opinions expressed herein are my own and may not represent those of my employer.



Wed, 30 Jun 2004 06:59:48 GMT  
 break considered harmful

Quote:

> [1] I made a mistake once.

You thought you were wrong about something?   ;-|

--

|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Opinions expressed herein are my own and may not represent those of my employer.



Wed, 30 Jun 2004 07:00:50 GMT  
 break considered harmful

Quote:

> In C, the use of break in other than switch statements is
> considered harmful...

As has been pointed out, not universally by any stretch.

Quote:
> When control reaches this point (loop exit), the programmer should
> want to know what conditions apply.  His natural inclination is to
> examine "condition".  However, he is *WRONG*.

Isn't this similar to arguing against certain C idioms because they
are "confusing"?  To which the usual counter is, "Not to anyone who
really knows C."  So one question is, who are we writing for?  The
lowest common denominator?  Ick.

I just don't think any decent programmer should be thrown by the
construct:

    while (condition)
    {
        /** code, code, code... **/

        if (some_condition)
            break;

        /** code, code, code... **/
    }

This is, after all, a common idiom, is it not?

I agree with Kaz's perceptions of the problems with the label if a
goto is used.  What's worse, the use of a goto seems to throw any
argument about structured programming out the window.

And speaking of which, I realized why break/continue do not dismay
me with regard to structured programming.

Step back.  Under the hood, it's machine code, and it's filled with
branches.  Programming languages provide an environment to write code
that--at that high level--appears structured, although under the hood,
it's just the same machine code.

To me, the break/continue statements (and please spare me any grief
that there's no "break/continue" statement in C...it's cute when used
against the C/C++ phrase, but you know perfectly well what I mean here).

Where was I?  Oh, yeah.  To me, the break/continue statements *are*
high-level, *structured* statements.  They may look like goto's, but
they are so restricted in where one can go to, that I don't see them
in that light at all.  What they look like, to me, are constructs
that allow an almost invisible form of structured programming.  When
you encounter a break or a continue, there's only ONE PLACE you can
go.

In fact, what they do is *hide* the very machinery that some folks
expose by writing their loops to use signal variables.  And that's
why I find that approach such a eyesore.  It ignores the high-level
constructs of the language and exposes the primative, almost machine
code-like, innards.

Not for me, thanks.  I entirely prefer the clean and--to me--structured
constructs provided by the language.

--

|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Opinions expressed herein are my own and may not represent those of my employer.



Wed, 30 Jun 2004 07:17:19 GMT  
 break considered harmful

Quote:


> > Which is why C should get a leveled break.

> ROFL!  (That WAS satire, wasn't it??  If not, oops, sorry! :-)

Another language already allows labelled break and continue.  Why shouldn't C?


Wed, 30 Jun 2004 12:16:42 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Hungarian Notation Can be Considered Harmful (was Re: GCC/G++ vs Other guys)

2. cast considered harmful?

3. strcat() considered harmful

4. Gotos considered harmful (Dijkstra vs. Knuth )

5. Optimization considered harmful

6. Optimization considered harmful

7. EOF considered harmful

8. bitfields considered harmful?

9. C Problem (or, GOTOs considered harmful)

10. Variable Initialisation Considered Harmful ?

11. Mixed prototyping considered harmful

12. GOTO considered harmful

 

 
Powered by phpBB® Forum Software