Tom Lachecki

After struggling with my Windows 7 grinding to a halt over the last few months, I finally managed to get it up to speed again. Although some of the suggestions below may seem obvious, I've selected them from a longer list as my recommendations for the four best ways to speed up your Windows 7 installation.

Number Four

Disable the taskbar "jump lists" to see a small improvement in the responsiveness of the taskbar in general. I never open "recent items" from a jumplist, mainly because I keep my favourite applications (mIRC, Thunderbird, my media player, Notepad++ and Firefox) open at all times anyway.

Number Three

Disable Explorer's "libraries" to speed up Explorer loads. Even if you use a shell replacement (like the fantastic Directory Opus), you're still using Explorer for things like "Save As…" dialogs.

Number Two

Disable Explorer's "homegroup" to yield the biggest speed benefits in launching Explorer instances. I don't need to interface with two system services to choose where to save a photo from imgur.com, thank you.

Number One

Delete everything in C:\Users*\AppData\Local\Temp that's older than two days and not currently in use. I don't know whether my hard drive is particularly badly fragmented but I noticed an immediate and significant improvement in general responsiveness.

Bootnote

Let me know if any of these help you!

I was reading an article the other day entitled "Adding Perl to Your C++ Applications", a rather interesting read. However, like so many other sources, it refers to the "STL", despite the fact that very few people still use the STL (which was designed at SGI). [1]

Parts of the C++ Standard Library were based on parts of the STL, and it is these parts that many people (including several authors and the notoriously error-ridden cplusplus.com) still refer to as "the STL". However, this is inaccurate; indeed, the C++ standard never mentions "STL", and there are content differences between the two. [2]

So I am here to ask everyone to stop using the erroneous term "STL"!

Assuming that you are referring to the library that is defined by the C++ standard, the correct terminology is C++ Standard Library and a suitable abbreviation is stdlib, or libstdc++ to cheekily borrow the name of GCC's implementation.

I [arguably] wouldn't usually be so pedantic, but this is an extremely prevalent mistake and I am doing everything I can to prevent the new generation of C++ programmers from falling into this trap.

Naturally, there are those who have noticed this disturbing trend as I have, but who disagree that it's problematic. They tend to argue that language evolves and that the term "STL" has become a popularised and widely-accepted synonym for the current C++ Standard Library. [3]

Were this true then there wouldn't be much of a practical problem; it'd simply be irritatingly incorrect in the strictest sense. Alas, it's not. "STL" is rarely used to refer to the bits of the stdlib that happen to be based on the SGI STL. People think it's the entire standard library. It gets put on CVs. And it is misleading.

As one commenter on Jesper's article explains:

The issue is one of con­fu­sion. Which parts of the stdlib are in the STL? iostream? string? slist and oth­ers in the SGI STL, pro­vided by some imple­men­ta­tions, but not in the stan­dard? Addi­tions from TR1? What about 0x? Even though most peo­ple have very sim­i­lar def­i­n­i­tions, they are all slightly off from each other.

Why not just say "stdlib" if you mean the C++ Stan­dard Library?

How­ever, I some­times do want to talk about the SGI library — or rather the ideas and idioms it made pop­u­lar in C++, even if not the actual source code.

So let's just stop it!

Update 05/03/2011: See this answer to a StackOverflow post that came out of this article, for a more detailed explanation of my standpoint.

[1] "When the STL Isn't Enough: Adding Perl to Your C++ Applications", Ken Fox, 1998
[2] C++ as defined by ISO/IEC 14882-1998 & ISO/IEC 14882-2003.
[3] "STL, language lawyers and pedantry", Jes­per Alf Dam, 2010

Image used with permission
© Elizabeth O. Dulemba, Children's Book Author/Illustrator
Visit www.dulemba.com to learn more and download more coloring pages.

One of the evilnesses of the C++ Standard Library is that implementations — be they GCC's libstdc++ or the Dimkumware implementation used by MSVC — are free to have their headers include other standard headers as much as they like. This can lead to confusion. For example, the oft-given:

#include <iostream></p> <p>int main() { std::cout << "Hello world\n"; }

This is technically incorrect!

Although the most popular standard library implementations currently just so happen to have an iostream implementation that itself includes ostream (for any internal reason), you should include the header ostream yourself to gain access to ostream's operator<< that you use above. If one day your toolchain's code gets restructured and iostream no longer includes ostream, your build will break because you've included the wrong header.

Unlikey though it is to be a problem in this specific case, it's important in general to include precisely the right header for the job according to the documentation, and not one that just seems to work for you at any given time. Even if you don't care about immediate portability or proper correctness, then at least think about future maintainability.

The corrected snippet reads:

#include <iostream> // for std::cout</p> <h1>include <ostream> // for std::ostream::operator<<</h1> <p>int main() { std::cout << "Hello world\n"; }

(In the below article, geordi is used to test snippets. "BARK" is a geordi macro that outputs the function name of the enclosing scope.)

Here I briefly explore a common inheritance gotcha and its usual solution.

Normal overloading

struct A { void lol(int); void lol(string); };

A::lol(int) and A::lol(string) are actually different functions.

Overloading with inheritance

struct A { void lol(int) { BARK; } }; struct B : A { void lol(string) { BARK; } }; int main() { B b; b.lol("d"); } //B::lol(string)

struct A { void lol(int) { BARK; } }; struct B : A { void lol(string) { BARK; } }; int main() { B b; b.lol(3); } //error: no matching function for call to 'B::lol(int)'

Here one might expect the second example to work, with the output "A::lol(3)" since the function clearly exists and should be inherited.

But in our example, B::lol(string) hides or "shadows" A::lol(int) so the lookup doesn't work. Since there is the function with the name "lol" in B, when you try to call b.lol(3) the compiler never bothers to look for other functions with the name "lol" that might be in A.

We could be a bit more explicit with our function call:

struct A { void lol(int) { BARK; } }; struct B : A { void lol(string) { BARK; } }; int main() { B b; b.A::lol(3); } //A::lol(int)

But that's a bit minging. It would be nicer to fix the lookup from within the class definition itself. To do so, we must bring A::lol(int) into scope of B with the using keyword so that the two functions lol(string) and lol(int) can live side by side in harmony.

With 'using'

struct A { void lol(int) { BARK; } }; struct B : A { using A::lol; void lol(string) { BARK; } }; int main() { B b; b.lol("d"); b.lol(3) } //B::lol(string) A::lol(int)

It doesn't matter where you put the 'using' statement; it won't ever cancel out B::lol(string), even if it comes after the function definition:

struct A { void lol(int) { BARK; } }; struct B : A { void lol(string) { BARK; } using A::lol; }; int main() { B b; b.lol("d"); b.lol(3); } //B::lol(string) A::lol(int)

Implicit conversions don't break this either:

struct A { void lol(A<em>) { BARK; } }; struct B : A { using A::lol; void lol(B</em>) { BARK; } }; int main() { B b; b.lol((B<em>)&b); b.lol((A</em>)&b); } //B::lol(B<em>) A::lol(A</em>)

struct B; struct A { void lol(B<em>) { BARK; } }; struct B : A { using A::lol; void lol(A</em>) { BARK; } }; int main() { B b; b.lol((B<em>)&b); b.lol((A</em>)&b); } //B::lol(A<em>) A::lol(B</em>)

So there you go.

Update 05/05/2011: Here's a really good explanation of the cause behind this shadowing.