Eclipse has IMHO the best configuration for selecting the files to tag with the "Derived" folder property. I am willing to put up with fact that it is slower and buggier than most of the competing solutions primarily because of how much easier it is to manage tagging for large projects. The indexer itself is slow for C/C++ files and fairly buggy (both the quick and full versions tend to hang on large projects a lot).

http://www.mojavelinux.com/blog/archives/2006/03/eclipse_resource_filtering_using_derived/

For extremely large projects, I still tend to use Visual SlickEdit (fairly expensive). It is extremely quick when updating tags for extremely large projects. I would prefer to use a cross platform open source editor, but none of the ones I have evaluated can match it in speed yet. Eclipse looks promising and might be able to close that gap in the future.

In terms of feature set, I am not aware of anything that can separate reader tags from writer tags like Source Navigator is capable of. The project was abandoned a few years ago, but some new maintainers have recently made a new release.

http://sourcenav.berlios.de/

If you do any work on headless servers or embedded systems, you will likely have to pick a console editor like vi or Emacs along with cscope in addition to whatever GUI tools you choose.

I've run into the problem of terrible STL performance in more than one occasion. The problem isn't so much that's impossible for it to be as efficient as C, in theory it could be. But to date compilers are more likely to turn a pointer simple assignment like tail->next=new into a single instruction store than pages upon pages of accessors calling accessors to call into templated functions in order to do the same.

If your idea of high performance is that both operations need to take less than a second, then you won't notice STL vs C performance differences. But if you need to guarantee that all of your array / vector / list operations complete within a few hundred processor cycles, optimizing STL is typically more work than replacing the entire thing with C code (including the extra debugging that doing the code in C will likely entail).

One of the things related to GCC performance is that you can use the LLVM C backend to generate C code from the C++ STL template source code. If you feed the C code back into GCC you can see huge speed gains with the compiler optimizing loops significantly better than if you feed it the C++ code directly. The downside is that debugging the LLVM generated obfuscated C code is a royal pain.

This is wildly dependent on whether your function call needs to store parameters on the stack and how slow a load-hit-store operation takes on the processor in question. Recent x86 processors are heavily optimized for these types of operations, but you cannot assume that the only platform your kernel is going to run on is x86 based.

You can easily execute 50+ non-dependent math operations in the amount of cycles that a single load-hit-store can take on a processor that isn't as heavily optimized as x86.

This is also one of the reasons why algorithms in C that do not need to reserve an extra register for the "this" pointer can easily outperform the same code written in C++ that requires the use of "this" pointers. With OOP in C++ you need to write everything as "statics" in order reduce the number of registers needed per function call to match the performance of C (GCC is rapidly improving lately and soon this may no longer be necessary).

Storing information on the stack from a register and reloading that same information near the top of the callee is very similar to what is described with float to integer conversions in the article below.

http://assemblyrequired.crashworks.org/tag/lhs/

I definitely agree that Windows has the capability to be a very stable operating system, but the lack of a central bug reporting system for third party drivers will make this nearly impossible to achieve for the bulk of the population. Nearly every Windows crash that I have encountered in 2K or XP has been driver related.

Unlike Linux and other similar operating systems, you cannot easily search any centralized forums or a bug tracker to get an idea of which hardware and its associated drivers is more likely to be rock solid stable. You can try to make an assumption based on your previous experience with a particular vendor, but even that can be hit or miss depending on the product. Chances are that at least one component in your system will end up with less than stellar stability and cause the entire operating system to destabilize.

Even if you are able to run a checked version of Windows with proof showing the problem driver crashing, getting various third party vendors to fix their closed source drivers is many times a wild goose chase. Knowing which vendors will respond quickly to issues can put you in a better situation, but there is never any guarantee. For a maintained driver on Linux, you can usually get a quick turnaround for any driver crashes that you run into. Even for unmaintained drivers, you still have the source code and the option to hire someone to fix the issue for you, if you aren't technically capable of doing it yourself.

How does this help the average Joe? Even though they are probably not capable of upgrading drivers on Linux, there is a good chance that they know someone who can (and you can bet they are on speed dial).