The constructor is private, so nobody can outright just instantiate a Kernel instance; in the meantime, the Kernel::getInstance() function will give you access to the static member Kernel instance that's created once during static initialisation.

Problem

However, this can cause problems when you bring more static data into the mix. Consider the following example:

Because the Kernel instance is created before the Utility instance's constructor is invoked, this is safe.

But if we flip the static initialisation order of the two objects, then we're trying to use a data member inside Kernel that hasn't been initialised yet:

Worse, if your Utility and Kernel instances are defined in difference Translation Units (loosely corresponding to .cpp source files in most projects), then their order of initialisation is completely non-guaranteed. It's pot luck as to whether your "simple" code will function at all.

Solution

It may seem contrived but this pattern has been seen in production code. To get around this issue when one static object depends on another static object, you can instead rely on the create-on-demand semantics of function-statics (an altogether different feature of the language):

In fact, in general it's best to try to avoid relying on static data members as these sorts of errors can go unnoticed for some time, and exerting control over C++'s static initialisation order is the sort of magic trickery left to gremlins and hyperdimensional beings.

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!

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!

—
[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.

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:

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

Normal overloading

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

Overloading with inheritance

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:

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'

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:

Implicit conversions don't break this either:

So there you go.

Unfortunately, AJAX is somewhat misunderstood by web application developers.

Synchronous XMLHttpRequests are those whereby your browser makes the data request to the server, then waits for a response, then continues with the script. Asynchronous requests, on the other hand, involve firing off the request, then carrying on with the script and with the general operation of the browser; when the server responds, a callback function is invoked. This could be seconds later or even never at all in the worst case.

The thing is, AJAX requests are rarely actually asynchronous, though many people insist upon calling every AJAX invocation "asynchronous" when in fact we mostly use synchronous calls. A better term would be "inline" requests.

The myth that synchronous calls add unnecessary delay to a web application is just that: a myth. In fact, most of the time, asynchronicity breaks a GUI. You usually have (a) no reason (b) no desire (c) specific reason not to allow multiple GUI responses at once; you want one button click to be handled before the next is noticed. This is because when a user presses button A they expect the result to occur — along with any side-effects — before the result of pressing button B is calculated, even if they press button B before the behind-the-scenes calculations of pressing button A are completed. It's human nature to expect linear procedurality, and breaking this expectation can lead to obscure bugs due to a discrepancy between the application's state on the server and its state in the GUI.

Unfortunately the obsession with "speed" and "efficiency" (which in reality are completely irrelevant here, but still) leads people to assume that they always want asynchronous calls, which may at times give the false impression of making an interface "faster" or "more responsive" when in fact usually they're simply incorrect and poorly designed.

I'll leave you to come up with your own examples and explore this idea.

The spaces vs tabs debate is an age-old one, with proponents on both sides fighting the cause as avidly as in the editor wars, browser wars, language wars and probably a bunch of others.

The spaces people argue that indentation should be applied by repeatedly pressing the spacebar key a certain, consistent number of times:

The tabs people, on the other hand, believe in pressing the tab key just once. This makes the next character align vertically to the next tab stop:

Personally I like to see code with its indents at 4-character widths, and when code has been indented nice and atomically with one tab per indent level, I can configure my editor to make that happen. When I make changes to the code and save it, the tabs are still there in place so the next reader could view it with tabs at 8-character widths.

With spaces, if I wanted to see a different amount of indentation I'd have to go through every line and add/remove spaces as required, and then that change would affect all other viewers of the code. It would also involve pointless updates to a version control repository.

Which do you use? If tabs, how far apart are your tab stops when you code? (For indentation, that is, which is the only time you should use them.) If spaces, can you explain the benefit to me? Please?

Let me start by asserting that the word "privacy" is vastly overused these days; in fact, it's not just that news outlets and newbs have the seven letters on reflex action speed dial, but that in most cases the concept of privacy is misapplied.

I shan't delve into detail on this point, but I continue to exist in a state of bemusement that thousands of teenagers, students and greying parents are publishing in what is essentially designed to be a public and largely open medium… then turning around and accusing that medium of somehow breaking the rules. In fact, I suspect it's more often the case that by the time it's clear that you've published that drunk status message directly to your boss, colleagues, grandmother and ex-girlfriend, it's too late to realise that social networking is not about private communication but about public broadcast. You wouldn't project images of your face onto every building in Lenton, then complain that people had looked at them; "privacy" has very little to do with it.

Anyway, the news is that Mark Zuckerberg — the software developer who took a great product, capitalised on luck and market demand, and then turned the product into a steaming pile of rotting vegetables — has promised to revamp Facebook's privacy settings amidst complaints that they have become "too complex" for users.

But for every change mentioned — the settings grids, the blanket application controls, the new defaults — there's a paragraph about how Facebook "may not have gone far enough". How much further can you go? And in which direction? If you add more controls, then you've broken the idea of reducing the issue's complexity; if you remove controls, you run the risk of giving users far less control.

In fact, there is nothing wrong with Facebook's existing configurability (and it's good to read that those existing controls will still be available in some form). The real problem is that the untrained don't actually use the controls, because they can't be bothered to learn how to use them. As said Simon Davies, the director of Privacy International, "the vast majority of people don't use privacy settings so the reforms are not likely to have as great an impact". It's far easier to expect Facebook to automatically determine, by reading your mind, exactly who should see what whilst you continue to voluntarily and openly reveal your most intimate daily secrets to the world.

What I really want to see is less complaining about the options on the privacy settings page and blaming Facebook for drunken messages distributed over the internet, and more personal responsibility. Internet applications, like most human inventions, are complicated tools the use of which must be learned. Unfortunately, society as a whole currently seems sadly ignorant to this idea, instead reliant on blaming service and infrastructure providers for not making things simple, complex, lightweight, comprehensive, automatic and fully configurable all at the same time.

The article I've linked to ends with the very helpful, well-reasoned and informative paragraph:

The European Commission described the changes as "unacceptable".

Excellent; thanks for that.

Bootnote

Zuckerberg's claim that "we don't sell your information and we have no plans to," while intended to allay fears that specific personal information may be clandestinely and explicitly sold for profit, is ironic given that Facebook makes its operational revenue from advertising on a site that actually exists based on the provision of information. In a sense, selling information is the company's entire business model.

Apparently Mark told BBC News that it was a "misconception" that the site relies on people sharing information to make money from adverts, but anyone who's used Facebook knows that the ads are tailored to what's on your profile… especially if your profile's just been banterously 'hacked' by mates who've changed all your listed interests to choices considerably less savoury than what they were originally.

All three are equivalent because arbitrary spacing is meaningless in C/C++.

The problem with C and C++ is that its built-in operators have multiple meanings. In particular * means "pointer type", "multiplication" and "dereference". My goal when picking a convention is to, as much as possible, avoid using one that jars with another.

Therefore, we'll ignore syntax 2 because it looks so much like multiplication.

Unfortunately, there is no clear winner between the other two as each has at least one hindrance. Syntax 1 has the following:

In the code above, ptr1 is a Foo*, but ptr2 is only a Foo. One might have expected both to be Foo*s. Syntax 3 avoids this by keeping the asterisk with the name:

This is really a throwback to C's desire to have you think in terms of "I am declaring a Foo to which ptr points".

Unfortunately, this is misleading to language newcomers because in fact you're not declaring or defining a Foo at all. You're merely declaring a pointer; you still haven't allocated any actual Foo for it to point to.

A newbie reading "int *a" might think he's created an int and now gets to use "the variable *a" to access it, when in fact this is not the case at all; dereferencing such an undirected pointer would be very dangerous.

Further, aligning the asterisk with the variable name looks like a dereference operation. One of the biggest stumbling blocks to language newcomers is the multiple meaning of operators such as * and & — learning the difference between * on the LHS as a pointer type indicator and * on the RHS as a dereference operator is not aided if you see code that always aligns the asterisk in the same way.

Additionally, the name of the type itself is "Foo*" (though array declaration and function type declaration syntax oddities do make this slightly more complicated in practice).

To summarise:

In conclusion:

Foo *p is rubbish; it has three cons and two pros. Foo* p is great; it has one con and four pros… important pros.

Thanks for reading.

Updated 31/07/2010: Improved table layout for clarity.

Some C++ programmers prefer to use copyconstructor-style initialisation syntax for clarity because it is the copy constructor that's invoked in both cases, not the assignment operator as one might expect from the use of the equals sign.

But I think clarity is the complete opposite of what you get. It can cause problems where you do not expect them, leading to complicated diagnostics:

Although the linker error makes sense if you know that you have declared a function and never defined it, the diagnostic does not really help you fix the problem if you did not see this coming and expected x to be equal to 0.

"Wait, what. I've declared a function?"

Yep! The only difference between a function declaration int(T) and a temporary construction int(x) is that T is a type whereas x is an expression. So:

In the last case above, because the int() has nothing inside the parentheses it can be parsed as either, and function declaration is always assumed in C++ where it's possible.

There are plenty of cases where a type simply cannot be in a situation like this, and in the other cases you can hack around it by forcing the declaration to become an expression with extra parentheses:

Still, even if just because of this, I avoid "int x(3);" and instead prefer good-old equals-syntax which, although it doesn't actually invoke the assignment operator, at least does what it says it does: it declares and initialises an integer variable called x, equal to 3:

Stick to this syntax and you won't have any trouble; problem solved.

Further reading

• [10] Constructors Updated! , C++ FAQ Lite
• C++ FQA Lite: Constructors