asrelu wrote:

"if(p)" is easier to write and also easier to understand instantly what it means. I'm sure the generated code is the same because the code optimization will elliminate the pointless evaluation of the logical expression from "if(p == NULL)".

I'm old school, too, and I respectfully disagree. I use "if (p)" when p is used as a boolean. (It might actually be an int, because some of the old-school C that I help maintain). This is reminding me that p is a flag. When I'm using a pointer, I use "if (p != NULL)". Sure, the compiler might optimize it to the exact same code as above but the content reminds me that p is a pointer. Just my two cents. Your mileage may vary. This package is sold by weight, not by volume. You can be assured of proper weight even though some settling of contents normally occurs during shipment.

I once interviewed with a company, got an offer, said "I think this will work" and took the benefits manual home. Long story short, a seven grand pay raise turned into a pay cut after purchasing benefits equivalent to my (then) current employer. So I turned them down. I talked to them about six months later, seeing if anything was different. Nope. Okay. Two years later, they contact me. They say they feel they made a mistake two years ago, would I like to talk to them? Okay. Multiple interviews. Things go great. IT director likes me. Okay, let's see the big job offer. They low-ball me. Maybe 4K more than they offered 2 years ago. And my salary has gone up maybe 6 or 8K during that time. Okay, this isn't going to happen. I called up the HR director and chewed her out. Accused her of wasting my time, wasting everyone's time. I was really annoyed and I let her know it. I didn't care about burning bridges, after three tries, I'm *never* going to work there. So a day or two goes by. I'm looking elsewhere. They call me and made a big offer. In fact, they hit my target number. So I said yes and went to work for them.

Stan Shannon wrote:

Fire bombing Dresden and Tokyo, Nukeing Hiroshima and Nagasaki.

As horrific as those acts of war may have been, they were within the realm of warfare. But we did not, as you but it, "meet the enemy on their own terms" and go far beyond their brutality. The USA did inter Japanese-Americans but we did not put them in gas chambers. Claiming that we exceeded the brutality of the Axis Powers in World War II while restricting the discussion to the battlefield is disingenuous. Ignoring Hitler's death camps and Japanese treatment of Allied POWs in a discussion of brutality during World War II is the intellectual equivalent of the old saw "Other than that, Mrs. Lincoln, how did you like the play?"

Stan Shannon wrote:

Yet isn't it odd that meeting our enemies on their own terms during WWII, and going far beyond their own brutality[...]

Wow. I didn't know we went beyond Hilter's death camps, the Nanking massacre, and the Bataan Death March.

Mike Gaskey wrote:

I absolutely refuse to fly United, the absolute worst airline in the country.

Not much experience with Northwest, I take it? ;)

OF course Republicans think their mental health is okay. Same way they are self-confident. People who do things badly are usually supremely confident of their abilities -- more confident, in fact, than people who do things well. [^] Denial turns out to be a chief coping mechanism for many manic-depressives [^]

I surrender to your superior logic.

SK Genius wrote:

Did we mention it is impossible to kill a virus?

That assumes that a virus is alive, not a universally accepted viewpoint.

NimitySSJ wrote:

He notes that, due to how compilers analyze your code, you want to keep it from "branching" (i.e. jump from line A to line B, like a conditional might) as much as possible. Goto's are so unpredictable and hard to analyze that they defeat the compiler's optimization technology.

Nick, I'm going to disagree with you here. goto's are completely predictable and unconditional. Consider the following psuedo-code:

if (a > b)
then
c = a
else
c = b
endif
'
'
if (a > b) goto 10 else goto 20
10 c = a
goto 30
20 c = b
30 continue

I contend that there is no difference in what the compiler can do in optimization. The difference is the human readability. While I've made the case here recently that some limited use of goto's are okay, I certainly never again want to deal with code that looks like the second case above. The one thing that you said that I will agree with 100% is this:

use it [goto] very carefully and sparingly

fat_boy wrote:

Here is the scpetics view preprsented by two scientists, Drs Christie and Spencer of the University of Alabama:

An expert in microwave sensors, Spencer teamed with Dr. John Christy from The University of Alabama in Huntsville (UAH) to analyze the data.[...] Although global climate models predicted global warming due to increased CO2 in the atmosphere should show up first and strongest in the troposphere, the first ten years of satellite data showed no sign of warming in that layer of the atmosphere. Through the years, that result has changed. The atmosphere is warming From Nov. 16, 1978, through June 30, 2007, the global lower troposphere has warmed about 0.4 Celsius (about 0.72° Fahrenheit), or global warming at the rate of approximately 1.4 C (about 2.52° Fahrenheit) per century. Most of the warming that accounts for that trend, however, has happened since January 1998 in the northernmost third of the globe. There has been little or no net warming in the tropics over the past 28+ years, while there is very slight warming in the southernmost third of the globe. While this warming is within the range of natural climate variation, some of the warming is consistent with human effects — especially warming in the coldest air over the Northern Hemisphere, according to Christy. "That cold air has very little water vapor in it, so if you add another greenhouse gas you have an opportunity to trap more heat. "When you go to the tropics, where there's lots of water vapor, the extra carbon dioxide doesn't have as much effect. As a greenhouse gas, carbon dioxide's greatest effect is in the driest, coldest places." [...] Global" surface thermometer networks show a warming trend of approximately 1.7 degrees Celsius per century — about 3° Fahrenheit. The satellite data show a warming trend of 1.4 C or about 2.52° F per century. [...] Finally, we recognize that climate change is real and that human activities are probably contributing to that change. [...] — Dr. John R. Christy & Dr. Roy Spencer [^]

fat_boy wrote:

[...] which cooled by .4 of one degree Fahrenheit from 1941 to 2001.

That statement, although accurately quoted, is not what the study says. They cooled by .4 of a degree from the 60-year period with midpoint 1910 to the 60-year period with midpoint 1970.

A comprehensive climatological study of [...] compared the average (mean) temperatures in Fahrenheit for the six decades from 1880 through 1940 and the following 60-year period ending December 31, 2000.

Unless there are side effects of the other conditions, your example is the equaivant of this:

if (condE)
{
...
}

Color me sceptical. I hope I'm wrong, but there have been many so-called breakthroughs in solar PV that haven't panned out.

CurtD wrote:

So what happens to your "goto" cleanup routine when an exception is thrown? I'll give you a hint -- it doesn't get called.

The goto doesn't figure into that. Just above it in the thread is another snippet of my code that doesn't use a goto. Same issue. What happens to the code after the while loop when an exception is thrown? It doesn't get executed. Once could argue that the problem is with exception. As I pointed out elsewhere, Joel Spolsky argues that exceptions [...] create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: (emphasis added) I don't quite agree with Joel. But there was a time, when I was debugging an app that another programmer had written, that I understood that completely. It was spaghetti exception handling. I never knew where I had come from. I'm not saying you shouldn't use exceptions. But they can be abused as badly as gotos.

Joe Woodbury wrote:

I've found that once you tolerate any use of goto, some developers will abuse it severely. Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms. I have learned this by experience. I have maintained a lot of code chock full of gotos, but I have chosen to use one precisely once in nineteen years of C/C++ programming.[...]

We have different experiences. I've seen very few goto's as a professional programmer ... wait, except for those FORTRAN days. Actually, that's going to tie into the point I'm about to make. Different languages have different program control mechanisms. I used to program in a language called Clarion. One of the constructs I likes in that language was the ability to write loop 1 times. No index variable. I would wrap it around a series of if/then/else if and break to exit early. In C/C++, I accomplish the same with this

while (true)   // loop 1 time, exit at bottom
{
    if (set (ifrFragment))
    {
        result = true;
        ifrTerm = ifrFragment;
        break;            
    }
    if (errorCode)
        break;

    if (keyword (TokenSubtype::Not) && term (ifrFragment))
    {
        result = true;
        ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment;
        break;
    }
    if (errorCode)
        break;
  // more lines snipped
   break;
}

Robert Surtees writes We used to do it to piss off the "never use goto" zealots years ago when forbidden to use 'goto xit' for handling error conditions. And he's right. I could have done the same like this, with one few level of indentation:

if (set (ifrFragment))
{
    result = true;
    ifrTerm = ifrFragment;
    goto exit\_;            
}
if (errorCode)
    goto exit\_;

if (keyword (TokenSubtype::Not) && term (ifrFragment))
{
    result = true;
    ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment;
    goto exit\_;
}
if (errorCode)
    goto exit\_;

// more lines snipped
exit_:

So in the first example, I'm doing goto's -- without using them explicitly. Anyway, to get to my point: since different language have different control

In your examples, I prefer the version with the gotos. I can't tell which of OpenFile() or ValidateFileFormat() or ValidateRecordExists() might throw an exception.

Rama Krishna Vavilala wrote:

Either way the aim is to write easy to understand code rather than follow the rules because it comes from Joel Spolsky or Kent beck or Martin Fowler.

I'm in complete agreement with you!

reinux wrote:

Is goto really that bad?

I don't think so. I started off in high school writing spaghetti basic with GOTOs all over the place. I didn't know any better and I'm not such many did at the time. Certainly Edsger Dijkstra did, with his 1968 letter Go To Statement Considered Harmful but no one back at Warren High School in 1971 had that notion. Along the way, I learned to write Structure Programming while taking Algol. I recall discovering that I could use GOTO in Algol and used it in a program. Dr. David E. Boddy wrote on my program in large red letters "No! NO! NO!!!". And he was right. I used it when it was unnecessary, mostly as a way out of a bad design. But there are times to use it. I recently posted a snippet of my own code with goto's over in Coding Horrors (this code wasn't the coding horror :laugh: although some may disagree)

if (keyword (TokenSubtype::Group))
{
    if (!group\_label (groupName))
    {
        errorMessage = myName + ": Missing GROUP label\\n" + errorMessage;
        errorCode = DL\_ERROR;
        goto exit\_;
    }

    if (!separator (TokenSubtype::Colon))
    {
        errorMessage = myName + ": Missing colon following GROUP label";
        errorCode = DL\_ERROR;
        goto exit\_;
    }

// etc...

A goto is to your control flow as a pointer is to your data. Use carefully and with discipline. And remember if you use one: even if you're right, it's like using a split infinitive; some people are going to think you're wrong.

reinux wrote:

Something about that extra bool and if/else really bugs me.

Me too. I think your example doesn't make much difference, one way or another. But if the loops are nested, you have to have break out of multiple levels.

Rama Krishna Vavilala wrote:

I never had any reason to use it [goto]. If you keep function small and use exception handling you don't need to use goto.

But are exceptions any better that goto's? Joel Spolsky might say no. In fact, in one of his articles, Joel writes that:

...I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: 1. They are invisible in the source code... there is no way to see which exceptions might be thrown and from where.[...] 2. They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function.

Now, I won't go out there as far as he did and say that exceptions are worse that goto's. But I don't see exceptions as being significantly better. A goto is to your control flow as a pointer is to your data. Both can be significantly misused. However, it is appropriate to use them at times. Joel's second problem with exceptions is too many possible exit points. I believe there should be a single exit from a function. I would rather use

goto exit_;
// many lines snipped
exit_:
return foo;

than have multiple returns in a function. It's too difficult when you have multiple returns and you need to modify the behavior to add a bit of logic at the end. At least, that's my opinion.