Declaring variables at the top of a function or program is bad idea. Consider the following:

void function()
{
int i;

  // use 'i' for purpose 1
  ...
  // use 'i' for purpose 2
  ...
  // use 'i' for purpose 3
  ...

  if(i == 14)
  {
    // crash the program
  }

}

At the bottom of the function, 'i' is the accidental work product of the last place that it was used. Suppose this function is 200 lines long? Is the user supposed to hand examine every single place a variable is modified in order to understand what its value is currently being used for? Instead, declare variables as close to the point that they are actually used and make sure that they go out of scope as quickly after that as possible to reduce confusion to later maintainers. Confusion is the root of all evil in s/w. Lowell used.

Thanks for the hints! I was hoping to find some utility program to help me, but I guess I'll just have to roll up my sleeves and get to work. thanks! Lowell

Does anyone know of an application or source code that can be used to walk down all the tree of all windows in a program? I'd like to write some test code that runs at my program's exit that visits all the windows in the program and prints information about those windows -- for example: 1. print the resource id of the window 2. print the window text (or small part there of) 3. if the window is a dialog, frame, etc, visit the sub-windows thereof and repeat the above I'm interested in doing some automated testing understand that the task of filtering windows from the list may be really high. Thanks, Lowell

I guess we'll just have to agree to disagree.

My personal preferences are not the issue -- cost benefit analysis is. Change does not equal improvement. Some is and some isn't. For example, a Dvorak keyboard is a clear hands down winner for technical reasons but it has not caught on because of the retraining costs. Do you use a Dvorak keyboard? If not, why? Since you asked about VI: No I don't like VI -- although there are some technical arguments in its favor. Emacs is a major improvement but both editors have suffered from the historical fact that they evolved in an environment rich in diversity: there were a wide variety of computer monitors and keyboards. Sadly, each vendor chose to innovate in different directions -- leaving no standard keyboard design and more importantly, no standard software interface to the keyboard. Thus the clunky and ridiculous key bindings in emacs became the expected norm -- because they worked everywhere. I, on the other hand, became enamoured with the IBM's SPF terminals -- which had lots of named function keys. While the editing paradigm there was primitive, it was somewhat standard due to IBMs ubiquity. Later when I was called upon to write a text editor for PC's and unix boxes to be included in my company's product (which ran in both environments), I made sure that the named keys on the keyboard were properly interpreted. By this point in time function keys had appeared on unix keyboards but, lo and behold, only small parts of the unix s/w base -- excluding emacs -- took true advantage of them. (You could trick emacs into it but it took more work than a lot of people wanted to do -- and you needed different settings for each terminal) And when I tried to make my editor portable in the unix environments, I found that the IT people didn't know how to set up the termcap stuff properly and make it work consistently on every customer site we tried to deliver on -- I finally just started auto-generating a user override to the term cap database as part of the editor installation. It was a never ending hassle caused by unconstrained innovation and lack of proper training -- including my own: most of the users already knew how to run either VI or emacs and thus didn't need a new editor, they needed a way to plug their own editor into the rest of our tools suite and have it work correctly. Even if my function key based editor was some sort of improvement, it wasn't enough to justify the cost of training the users or the sys-admins. Ok, let me throw in one luddite remark: icons are joke. T

The amount of effort put out by developers is unimportant. The question is this: is the negative impact to hundreds of millions of people outweighed by the benefit those hundreds of millions expect to get from the change? I strongly doubt it. Most people are not power users and the ROI on the training cost are never going to be recouped by the companies buying the s/w upgrade. I am not being a luddite, I am being a cheapskate.

Ray's point about the importance of innovations is a good one. However, training costs are not zero. How much productivity is lost when people are sitting at their desks scratching their heads trying to figure out how to use a feature that they had already mastered in the previous version? How much productivity is lost searching crappy help systems trying to figure out how to do the same thing they've always done but using new buttons, gestures, etc. How much of other people's time is lost when you finally give up and go ask your buddy and they get involved in a discussion of last night's game? My point is that change needs to be justified in terms of training costs. Point and click time is not really all that important -- we can move our hands very quickly. When a new design provides some truly "better" way then I'm very tolerant of change. But when its just a matter of adopting the latest cutsey fad then I feel that my software vendor is cheating me out of the time I have to spend learning their "new" approach. Instead of innovating in the areas of screen interaction, why doesn't microsoft make these products work faster

Absolutely, This post, too, is right on the money. There are two schools of thought about how humans operate: cognitivism behaviorism The cognitivists prize our ability to actually reason about the world and they think that user interfaces should be set up intelligently based on the specifics of the task at hand. The behaviorists think that people have automatic behaviors that are triggered by what they see and here -- and that these behaviors are triggered regardless of the logic of the situation. The behaviorist would suggest that the delete button be in the same place on the screen in all GUIs even if in some GUIs it was the only option. The cognitivist would say that in this case, only one button should be shown and it should be in the most convenient place on the screen. The cognitivists are idiots -- as are people who constantly redesign interfaces so that they look prettier. Everyone that I have seen trying to use the latest generation MS Excell hate the interface -- not because it is bad, but because they can't find things that have been confortable with for years.

Profilers help some but are not perfect. The easiest way, assuming you don't already have a profiler installed -- and sometimes even then, to tell which of two algorithms is going to be faster, is to write a program that calls both alternative and which gets the time before, between each alternative, and at the end of its run. Have the test run 1 million iterations of each case -- or maybe 10,000 if the the program is taking too long. The wall clock approach gets you a good rough estimate in all cases and in some few cases, it gives you better results. Memory caching often confuses profilers -- only a true test on real data using wall clock time will let you overcome these problems. Now, you can spend a great deal of time getting your cache architecture described to the profiler, but you'll still have to run a wall clock test to verify that your profile is configured correctly. If you haven't already done all this, maybe a wall clock test is good enough.

The code was not throwing ANY exceptions. The slowdown comes from using the C++ compiler options that enabled exceptions. In the microsoft VC++ compiler, exceptions are disabled by default and you have to use an option to turn them on. However, the point is mute at this point in time -- in order to use the STL on many compilers, you have to compile with exception support. Still, you want a function to be as fast as can be it should be declare in such a way that it does not support exceptions. This may not apply to interpretive languages which are fundamentally slower than compiled languages anyway.

Yeah - that would be nice. I wonder if there is a way to get VC++ 2003 to dump the processing of the thrown exception so that by the time we get to the breakpoint on the in the catch handler, we can at least see the trace back to the throw point. I'll see if there is something I'm missing in output window from the debugger -- but I've looked before and couldn't find it. Of course, my wife says I couldn't find my nose on my face. I'll spend a little more time checking. Wish me luck.

Yep, debug builds for sure.

Hopefully, you'll find a way to help me see the info that I'm not currently able to see. However, in the catch handler, it is the stack trace of the throw point that matters, not the stack trace of the catch block itself. Further, what you'd really like to have is to be able to put a breakpoint in the catch handler and have the debugger understand the throw point and show you the variables in the stack frame of the throw point. Obviously, you can cause the debugger to stop when the throw occurs, but in VC++ 2003, you are not able to filter out throws that you are not interested in. For example, the CFile class throws exceptions for lots of silly reasons. If tell the debugger to stop on all throws, I'm constantly hitting throws which must be ignored -- and I don't know of any way to tell the debugger not to stop at at a particular throw point. If you know of a way to do that, please let me know.

I agree completely that there is no magic solution. As for my comments about exceptions slowing things down, I have measured it myself with several compilers. Merely compiling with exceptions turned on causes between 5 and 25% slowdown in algorithms that access large amounts of memory to, say, exhaustively search a large in-memory data set. I do understand that this is a rare kind of program to be writing, but everything has its place. Sometimes exceptions really don't matter for performance -- for example if you are doing a lot of system calls. None the less, I really wish they hadn't been added to the language. Other people are getting to force their annoyances on me as a developer, and they don't don't even have to write good documentation explaining the exceptions. This could also be true with error codes -- but they are a lot easier to debug than exceptions given the limitations of the tools available to me. We'll just have to agree to disagree. Peace, Lowell

A stack trace in the catch block (using VC++ 2003) does not show you where the throw point, it only shows you where the catch currently is -- that is to say the caller of the function that catch occurs in. Perhaps I am just ignorant of how to find the throw point in VC++ 2003, please enlighten me if you know -- I will be forever grateful. (truthfully!)

Thanks for your reply. Yes everything you do slows things down, but Stroustrup points out that in C++ exception handling adds a lot of time -- far more than error handling. In the interpreted languages, it likely makes less difference due to their already sluggish behavior. If exceptions are used only for truly exceptional situations, then the performance impact may be negligible. In an earlier generation of HP compilers, there was a 25% overhead if you turned on exceptions in our application that accessed multi-gigabyte data sets. The problem turned out to be that loop unrolling didn't work as well with exceptions turned on. However HP has fixed this problem and you only get about a 5% overhead. However, if you have a big supply chain planning application that takes 12 hours to run, that 5 percent matters. Yes, exceptions can be mis-used like many other features. But some features are more prone to mis-use than others. Exceptions anre an institutionalized laziness. They give the developer the idea that exception handling is someone else's problem, I just have to report the problem. And low and behold, every problem becomes worthy of an exception. Why should I have to do that grunt work? Yep, error codes can be easily ignored. But so can exceptions: you just catch(...) and do nothing.

The problems with exceptions include: 1) they slow down the execution of the program, but more importantly 2) they are used by lazy people to defer work that they should be doing to other people who don't understand the code that threw the exception and then have to spend hours tracking down things that should not have to know about the underlying packages in order to understand what is really wrong 3) handling exceptions is far bulkier than responding to error codes. Sometimes ignoring error codes is just fine -- like when I delete a file that doesn't exist, I really don't give a rodent's behind that the delete file function returned an error. If I wanted to know that the file existed, I'd have used some form of status call to get is permissions and make intelligent decisions before calling file delete. 4) the debuggers don't give you a "came from" trace when you put a breakpoint in the catch() clause -- this means that you have to have "time of throw" breakpoints and this means you stop in the debugger way too often because people other coders are throwing exceptions for things are not exceptional! 5) in C++ throwing exceptions and calling operator new directly (ie without storing it in a class object or some kind of smart pointer) are incompatible programming methodologies, but third party packages are throwing exceptions and their lazy design decisions means your code is suddenly buggy. uh uh uh uh .... calming .... down ... exceptions == yuk

No one language solves all developers needs. I have discovered that a good script language that lets me process text from log files is essentially to power programming. Personally, I like bash combined with sed, grep, tr, sort, join, etc. I like this combination for text processing because it is very easy to experiment with my scripts before committing them to text files. The bash command line allows an expert to do very complicated things in a very simple manner. I understand why the power of perl and java seem seductive, by I'm used to the simple mechanics of bash et al. As for a primary programming language, I think that that decision depends on the availability of useful libraries appropriate to your task. That is, although I love C++ and wax poetic about it on my web site, the truth is that if you have to write all the code for yourself, you are doomed to failure. Unfortunately, the basics of a language can counteract any positive effect of large libraries. Just look at FORTRAN: it has lots of libraries but almost nobody uses it. People dropped COBOL like a hot potato as soon as something, ANYTHING, appeared. The key is selecting is to understand what your personal situation actually is. For example, suppose you are the only one ever to be on the project. In this case, choose the language you already understand. If you are going to be part of small team of whose members are already known, find out the most commonly understood language among them and stick to that. But for goodness sakes, don't let everyone choose their own language. Pick ONE. If you are going to be part of a growing team, you need to deal with issues like code readability: how good is everyone going to be ad fixing bugs in everyone else's code. The availability of libraries in that language that already do exactly what you want is important, but not all important. You wouldn't pick FORTRAN just because libraries are available -- unless you couldn't get them in any other language under any circumstances. I like C++ for most personal use, other than scripting purposes, because I think that the language was desgined by experts for experts and I am an expert. It is gives you great performance and if written correctly requires very little debugging. Unfortunately, many people attempt to write C using the C++ compiler and this is a BIG NO NO. For example, you should never call malloc/free at all. You should never call operator new unless: 1. you are initializing an auto_ptr 2. you are in the constructor for a

Dangling pointers are no more likely in C++ than in C, Pascal, or assembly language. Further, dangling pointers in C++ are easily avoided by following this rule: Don't use operator new unless: 1. you are passing its return value to an auto_ptr 2. you are writing a constructor and you know that there is a delete of member holding the pointer in the destructor I know this works because I use valgrind, purify, and bounds checker. Even if you are not worried about forgetting to delete things yourself, C++ pretty much requires that you obey these rules because of exceptions. Some darn fool function that you call that was written by someone else is likely to throw an exception and so you get stuck planning for exception even if you don't write them yourself. As for the crowd who want to brag that Java/C#/Ruby don't have dangling pointers, I say this: I'll tried my C++ program performance for yours anytime -- especially in a large, long lived program. If you just learn to use the language, its not that hard to avoid all the problems these interpreters are supposed solve -- particularly since the STL came into C++. Most of the C++ language portability issues disappeared around 2002. At that time, porting a large Java application to Sun, Windows, HPUX, and AIX was still a challenge due to minor differences in the VMs. I don't know about nowadays though. Sorry -- as you can see I'm a C++ enthusiast. Lowell C++ Evangelist http://cplusplus.bordoon.com/index.html

And its equally facile with text and graphics!