• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Programming Help

Urgh, that was a mistyping.. I meant foc-breaking statements, like goto.

Break statements are necessary for the use of switch. I have never used goto or continue in the 6 years I have been programming in C, and I have never used break for anything other than switch statements. I also do not simply flag the iteration terminator when I want to break out of a loop; if your code is well structured you simply will never have to do this.

But you're reading code complete, so you would know what I'm talking about.

Okay, I'll bite. I have been programming for 15 years now, with a substantial portion of that in C. I have worked on projects from a few 10s of thousands of lines of code up to a couple million. I have used goto... a lot. In nearly every case, it has been for error handling. So for the sake of argument, let's say you have the following code:

Code:
while(condition1) {
  if (condition2) {
    for ( i = 0; condition3; i++ ) {
      val = networkOperation(&data[i]);
      if ( val == -EHOSTUNREACH ) {
        // catastrophic router failure outside our system!
        retVal = -EHOSTUNREACH;
        goto err_exit;
      }
    }
  }
}

err_exit:
if ( resource1 ) free( resource1 );
if ( resource2 ) free( resource2 );
return retVal;

How do you efficiently (both in terms of maintenance and code execution speed) handle a deeply nested catastrophic error that can only be caught at runtime (in this case I'm supposing that the network went down in the middle of a series of transactions)?

If you're lucky, you're using a language with exceptions... but exceptions are goto's with a little more structure. In plain C, how do you handle that? I'm very curious because I'm overseeing about 100,000 lines of code right now, and hardware failures in the middle of your program are expected. I don't particularly like goto's, but they are the cleanest way to deal with code that looks a lot like what is above.
 
How do you efficiently (both in terms of maintenance and code execution speed) handle a deeply nested catastrophic error that can only be caught at runtime (in this case I'm supposing that the network went down in the middle of a series of transactions)?

I am going to assume that he is using a boolean flag of some kind, presuming that he bothers to write error-safe code (many programmers choose not to, or are expressely told to allow a different development team to handle that)

The problem with such a method is that it is not functionally equivilent, nor is it easier to read. There remains no 'visual' clue to the flow regarding such booleans. The method you bring up does give visual clues, however:

If you're lucky, you're using a language with exceptions... but exceptions are goto's with a little more structure.

Exceptions in my experience are really really really slow gotos. Again, not functionally equivilent. Exceptions are meant for exceptional cases and in your example that is definately the case. It is not meant as a general flow control method.
 
Code:
for (int i = 0; i < myList.size(); ++i) { 
    Thingy item = myList.get(i);
    if item.doesWhatIWant()
        return item;
}
I don't know about you, but I like the second one better, and well-structured be damned. If I was to use a foreach loop in the second example (and I would), the second one is even shorter. Maybe your situation is different, but it's in these sorts of loops that I most commonly come across people refusing to break early, and I must say, I take great delight in refactoring that code out of existence... let's hope we never have to work together!

I prefer
Code:
for (i = 0 ; i < myList.size () && !myList.get(i).doesWhatIWant () ; ++i) ;

if (i <  myList.size ())
{
    return myList.get(i) ;
}
else
{
// however you report not found
}

The reason is that you can tell at a glance what the exit condition of the loop is. That's not so important in your case, but if the loop is long and complicated it makes it easier to maintain.

IMO, break and continue should never be used within a loop since they disguise complexity.
 
Okay, I'll bite. I have been programming for 15 years now, with a substantial portion of that in C. I have worked on projects from a few 10s of thousands of lines of code up to a couple million. I have used goto... a lot. In nearly every case, it has been for error handling. So for the sake of argument, let's say you have the following code:

Code:
while(condition1) {
  if (condition2) {
    for ( i = 0; condition3; i++ ) {
      val = networkOperation(&data[i]);
      if ( val == -EHOSTUNREACH ) {
        // catastrophic router failure outside our system!
        retVal = -EHOSTUNREACH;
        goto err_exit;
      }
    }
  }
}

err_exit:
if ( resource1 ) free( resource1 );
if ( resource2 ) free( resource2 );
return retVal;

How do you efficiently (both in terms of maintenance and code execution speed) handle a deeply nested catastrophic error that can only be caught at runtime (in this case I'm supposing that the network went down in the middle of a series of transactions)?

If you're lucky, you're using a language with exceptions... but exceptions are goto's with a little more structure. In plain C, how do you handle that? I'm very curious because I'm overseeing about 100,000 lines of code right now, and hardware failures in the middle of your program are expected. I don't particularly like goto's, but they are the cleanest way to deal with code that looks a lot like what is above.

In your example, you are using gotos to simulate exceptions. That's OK because you don't really have a choice in C. It's pretty much the same as using gotos to simulate while loops in assembler language.
 
I prefer
Code:
for (i = 0 ; i < myList.size () && !myList.get(i).doesWhatIWant () ; ++i) ;

if (i <  myList.size ())
{
    return myList.get(i) ;
}
else
{
// however you report not found
}
The reason is that you can tell at a glance what the exit condition of the loop is.
I have to say, I'm not so keen on that (but then I would say that, wouldn't I?)

I think empty loop statements are something to be avoided. As is cramming too much into the loop initialisation statement. Taken together, those are pretty good symptoms that the wrong loop construct is being used.

Also, using the loop index after the loop has finished is a pretty dodgy practice.

That's not so important in your case, but if the loop is long and complicated it makes it easier to maintain.
That's true, but then I try and avoid long and complicated loops in the first place. I do scientific computing, so I see such monstrosities in half-baked conversions of Fortran-to-Java a lot, but they can be wrestled under control in most cases.

IMO, break and continue should never be used within a loop since they disguise complexity.
This means you can never use continue. I think one should cast a critical eye over the use of breaking statements, but not rule them out outright.

BTW Skylark, if you're still reading, I finally read the chapter on loops in Code Complete, and it seems to me that Steve McConnell recommends almost the opposite of what you've been advocating.
 
In your example, you are using gotos to simulate exceptions. That's OK because you don't really have a choice in C. It's pretty much the same as using gotos to simulate while loops in assembler language.

Yes, in my mind a goto is the only clean way to handle this. I was just trying to figure out where Skylark was coming from such that he has NEVER had to use a goto, or use a loop termination flag, and has been programming in C for 6 years.

Unfortunately I didn't slow down enough to notice that he hasn't posted to this thread in a long while and has probably given up.
 
Yes, in my mind a goto is the only clean way to handle this. I was just trying to figure out where Skylark was coming from such that he has NEVER had to use a goto, or use a loop termination flag, and has been programming in C for 6 years.

Unfortunately I didn't slow down enough to notice that he hasn't posted to this thread in a long while and has probably given up.

I suppose if you absolutely had to do it with out using gotos you could go for something like this:

Code:
inline int ItsAllGoneWrong(int ErrorNo, CustomType *resource1, CustomType *resource2){

           if ( resource1 ) free( resource1 );
           if ( resource2 ) free( resource2 );

          return ErrorNo;
};
with it being called like this:

Code:
return ItsAllGoneWrong (-EHOSTUNREACH,resource1,resource2);
Classes or namespaces would remove the need to pass pointers to the resources without cluttering up the global namespace. However people who object to gotos often object to sticking a return in the middle of code so you still can't win.
 
Classes or namespaces would remove the need to pass pointers to the resources without cluttering up the global namespace. However people who object to gotos often object to sticking a return in the middle of code so you still can't win.

I think the biggest complaint (and I have it as well) would be that you are hiding the cleanup code for one function inside another function for no obvious reason.

Oh, that and its not functionally equivilent.. but I suspect you already knew that.
 
I think the biggest complaint (and I have it as well) would be that you are hiding the cleanup code for one function inside another function for no obvious reason.
Absolutely, but in my defence the question was, "How can I do this without gotos?" Not, "Should I do this with out gotos?"

Oh, that and its not functionally equivilent.. but I suspect you already knew that.

Actually I didn't. What definition of functionally equivalent are you using? I'd normally say that (2x)(x) and (x + x)(x) are functionally equivalent but that's clearly not what your talking about.
 
Actually I didn't. What definition of functionally equivalent are you using? I'd normally say that (2x)(x) and (x + x)(x) are functionally equivalent but that's clearly not what your talking about.

Well, it would be functionally equivilent iff the inline directive was respected.. know any C compilers like that? They inline whatever they damn well please in my experience.

I don't mean 'not functionally equivilent' in the 'works-like' sense but rather in the sense Knuth would mean: They literally do different things! You would not expect a compiler to produce the same instructions which means different performance.
 
Well, it would be functionally equivilent iff the inline directive was respected.. know any C compilers like that? They inline whatever they damn well please in my experience.

I don't mean 'not functionally equivilent' in the 'works-like' sense but rather in the sense Knuth would mean: They literally do different things! You would not expect a compiler to produce the same instructions which means different performance.

I was kicking some code about with one of the other guys in my department today and playing with the disassembly of inline functions. The current edition of Visual Studio seems quite respectful of inlines.
 
Aiya.

Typical programmers...

This guy asks

"What is a good language for writing programs to work through fairly simple algorithms?"

and you all go off on tirades about which language is "better". Argh!


Okay, this is directed at you pig.

The language FOR YOU with the; EASIEST syntax, simplest to use interface, which is built to run on WINDOWS XP will probably end up being Visual Basic.Net. Pick up the FREE "express" version right here: msdn.microsoft.com/vstudio/express/ (Sorry if I'm breaking any rules by posting a link. I don't see any way around it in this paricular message)

As for books, I can't really recommend any beginner ones as I have yet to come across a decent "you program this way" one. Most superb books in the computer industry happen to be more language reference than programming concepts. The absolute best thing you can do to learn is what I did many-a-years ago.... Learn the absolute basics and then screw around until stuff actually works. Start by doing a google search for something like "Visual Basic.NET 2005 Beginner" (without the quotes). The great thing is that, these days, you can go to internet forums and ask questions if in the end you can't figure out some obscure detail.

So forget all these guys, grab some free and easy to use development software, and start PLAYING!!

Speeder

(Sorry about the generalization of "all", but I'm not ready to commit to the time needed to respond to each and every one of you. ;o)

(Since I'm under 15 posts the BB software is making it to much of a pain to use quotes)
 
Well if hes going to be using VBA then he might as well just use the built-in VBScript that is on every windows platform since I guess Windows 95, and not bother with a 2nd program such as Excel.
The VBA option is a great idea for him. I don't think VB script offers the IDE benefits you get from the Microsoft Office Suite. You could do any of the programming through Excel, Access, Word, or PowerPoint, or even Visio.
 
EDIT: Also please don't use visual BASIC, or anything with the word BASIC in it for that matter. In words of one greater than I, "It is practically impossible to teach good programming style to students that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." (Edsger W. Dijkstra: Selected Writings on Computing: A Personal Perspective)

That might seem a little dank considering you've already used BASIC in depth, however there is still hope for you! :P
Dijkstra was talking about BASIC or BASICA not Visual Basic which is object-based nor about Visual Basic.NET which is fully object-oriented.
 
VBA is essentially VB6 with major limitations. Unless you're using it specifically because you need to interact with Word or Excel in a way that is distributable to other users as a single file, I would not really recommend it....

Better to go with VB.Net 2005 Express Edition and get a somewhat full featured IDE geared towards programming. The VBA IDE is pretty lacking. Especially when it comes to telling a novice user why their application won't compile.... :(
 

Back
Top Bottom