Apparently this started around Thunderbird v3, and here's how to fix it all the way up to v12:

• Tools > Options
• "Advanced" tab
• "Config Editor…"
• "I'll be careful, I promise!"
• Set preference network.protocol-handler.warn-external.http to true.
• Click on some link in an existing email
• You now get the choice of which browser to use. Do not select Firefox. Instead, choose "Other" and locate firefox.exe on your hard drive.
• "OK" everything.

Apparently Thunderbird works best when you pretend to it that its sibling Firefox is a third-party application that needs a simple shell invocation.

But the fact that the standard text on C++ all but ignores something as core to the internal operation of C++ as the Stack is telling indeed. In my experience, this is symptomatic of the disconnect between programming language and underlying implementation that exists in the academic mindset.

In fact, it's very deliberate, and has nothing to do with academia. You shouldn't need to know about implementation details like a memory stack or heap because (a) you're writing in a programming language that abstracts those details away from you, and (b) they are implementation-specific. In Bjarne's case he's writing only about C++, not how some specific platform implements it. It's a book about the language, not the computer that compiles it into another language.

Understanding this abstraction is key to writing good, portable code. That's why he's done it and it's a good thing.

When books jump into talking about a "stack" or "heap", they are mistraining people into thinking that these are part of C++ when they are in fact programming with a combination of technologies including C++, machine code, a stick of memory, an OS… and Darby seems to have fallen into that trap, as his article gives the impression that he believes a stack is a core part of C++ itself. Indeed, Bjarne is correct to talk instead about the notion of storage duration, which is the only thing the C++ language defines on the matter.

Of course, that's not to say that such details should be forever ignored or that we should pretend that, say, an x86 machine doesn't typically use a stack. Certainly in the game development world, a programmer must be aware of lower-level implementation details. I'm not advocating some academic approach that completely removes real-world components from the equation.

It'd just be helpful if Darby didn't pretend that these lower-level details were actually part of C++ at all.

GNU Make is powerful and, although it's been superceded in some circles by wrappers like automake or all-out replacements like CMake and scons, for simple distributions it's still got teeth.

It's not without its pitfalls, though. In the below Makefile, not only do I have to create my own string equality function eq, but the outcome is not what I'd have expected:

# Comparison function
eq = $(and $(findstring $(1),$(2)),$(findstring $(2),$(1)))

# Variables
suf = $(if $(call eq, $(NATIVE), 1),-native,)
build_dir = build$(suf)

# Targets
.PHONY: a b

# (should yield "build")
a: $(build_dir)

# (should yield "build-native")
b: NATIVE=1
b: $(build_dir)

$(build_dir):
     @echo $@ ($(build_dir))

Outcome:

# Flag behaving properly:
~$ make a NATIVE=1
build-NATIVE build-NATIVE
~$ make b NATIVE=1
build-NATIVE build-NATIVE

# Flag not behaving properly:
~$ make a
build (build)
~$ make b
build (build-NATIVE)

In target b with no flag initially given, the sub-target build is being invoked rather than the build-NATIVE target that I'm really after, as indicated by the output of $@. Notice how $(build_dir) is correct within the rule itself.

In real life, my Makefile will accept a flag describing the target platform for the build; the default case is an ARMv5 cross-compilation, but a native build can be performed for local debugging. In addition, unit tests must be built natively as they are executed locally as part of the build process. So the idea is to override the target flag for the unit test target; then, even when mixing targets as in make check all, for the check target only a flag NATIVE is automatically set to "1" even though it was missing from the commandline invocation.

Alas, as shown above, although this works for instructions inside the encapsulated rule, the same is not true for the target itself (or its dependencies, of which we haven't written any here). This is because the Makefiles run in two phases: targets and pre-requisites are expanded in the "read-in" phase; my variable isn't reset until the "target-update" phase, in which only variables inside rules are expanded.

To work around this, we can make use of "secondary expansion". Applying it to the example above, using the details provided in the GNU Make documentation:

# Comparison function
eq = $(and $(findstring $(1),$(2)),$(findstring $(2),$(1)))

# Variables
suf = $(if $(call eq, $(NATIVE), 1),-native,)
build_dir = build$(suf)

# Targets
.PHONY: a b
.SECONDEXPANSION:

# (should yield "build")
a: $$(build_dir)

# (should yield "build-native")
b: NATIVE=1
b: $$(build_dir)

$(build_dir):
     @echo $@ ($(build_dir))

Outcome:

# Flag behaving properly:
~$ make a NATIVE=1
build-NATIVE build-NATIVE
~$ make b NATIVE=1
build-NATIVE build-NATIVE

# Flag not behaving properly:
~$ make a
build (build)
~$ make b
make: *** No rule to make target `build-foo', needed by `b'. Stop.

We're closer: target b is now at least attempting to invoke the correct sub-target build-foo. Unfortunately, secondary expansion only works for the prerequisite lists and not for target names, so in the case above the target build-foo doesn't actually exist.

The sensible thing to do at this point is to get that explicit value out of all targets and use patching matching instead or, better yet, employ AutoMake. But if the targets don't have obvious patterns and a build system switch doesn't whet your appetite today, and if you fancy a good hack, there is a complete workaround:

# create comparison function
eq = $(and $(findstring $(1),$(2)),$(findstring $(2),$(1)))

suf = $(if $(call eq, $(MYVAR), 1),-foo,)
build_dir = build$(suf)

.PHONY: a b
.SECONDEXPANSION:

# Should yield `build`
a: $$(build_dir)

# Should yield `build-foo`
b: $$(if ($$call eq,$$(MYVAR),1),$$(build_dir),)
        $(if $(call eq,$(MYVAR),1),,@make b MYVAR=1)

$(build_dir):
        @echo $@ ($(build_dir)) $(INHERITED)

Outcome:

[~]$ make a INHERITED=6
build (build) 6
[~]$ make a MYVAR=1 INHERITED=6
build-foo (build-foo) 6
[~]$ make b INHERITED=6
make[1]: Entering directory `~`
build-foo (build-foo) 6
make[1]: Entering directory `~`

By invoking make from scratch for the target tree under b, we can have our targets any way we want. Any other "local" variables are even automatically inherited by the sub-make (as demonstrated above by the INHERITED variable).

DynaTrace recently added support for Firefox 11 but, unfortunately, Mozilla's ridiculous high-speed release process means the major version number was bumped just over a month later to 12. The automatic upgrades that force themselves on me when I launch Firefox⁽¹⁾ mean I was on Firefox 12 almost immediately, and all this put together means that I couldn't use DynaTrace.

Fortunately, we can downgrade Firefox by locating the desired release from Mozilla's FTP site⁽²⁾ and installing it. As long as you don't go too far back in the release list, profiles should be reasonably safe from the downgrade; in this case, going from Firefox 12 to Firefox 11 was painless… and I got to enjoy the awesomeness of DynaTrace AJAX Edition.

Firefox will immediately begin downloading the latest version the next time you launch it, and will upgrade the time after that. So, at this point, it's worth going into Tools->Options and disabling automatic upgrades like I should have done originally.

It's time that Mozilla stopped this nonsense; incrementing the major version number so often is causing a tangible nightmare with add-on compatibility, and I cannot understand why the Firefox development team leads do not appear to care.

Note 1: Hey, Mozilla! When I launch my browser, it's because I want to visit a website, not because I want to upgrade the browser.
Note 2: "uk" stands for Ukraine, not the UK. You're looking for "en-gb", which I should already know. I mean, who was I kidding?

The following is not valid:

struct T
{
   static const size_t BUF_SIZE;
   char buf[BUF_SIZE];
};

size_t T::BUF_SIZE = 256;

// error: array bound is not an integer constant

Clearly, for any instance of T, the array bound could be found in a different translation unit and T's size would be incalculable.

However, since the following compiles and links, I came to wonder whether it's really well-defined:

struct T
{
   static const size_t BUF_SIZE = 100*1024;
   char buf[BUF_SIZE];
};

My standard-fu fails me so far…

struct GpsdWrapper
{
    GpsdWrapper(int gpsFd);
    ~GpsdWrapper();

    void poll_AS();
    void parse_AS();

private:

    static const size_t READ_BUFFER_SIZE = 100*1024;

    char   read_buffer[READ_BUFFER_SIZE];
    size_t buffer_pos;

    int gpsFd;

    boost::mutex  buffer_lock;
    boost::thread poll_thread;
    boost::thread parse_thread;
};

GpsdWrapper::GpsdWrapper(int gpsFd)
    : gpsFd(gpsFd)
    , poll_thread (boost::bind(&GpsdWrapper::poll_AS, this))
    , parse_thread(boost::bind(&GpsdWrapper::parse_AS, this))
{}

GpsdWrapper::~GpsdWrapper()
{
    poll_thread.interrupt();
    parse_thread.interrupt();

    poll_thread.join();
    parse_thread.join();
}

void GpsdWrapper::poll_AS()
{
    // {block signals}

    fd_set rfds;

    while (true) {
        boost::this_thread::interruption_point();

        timeval tv = get_timeout(); // {defined elsewhere}
        FD_ZERO(&rfds);
        FD_SET(gpsFd, &rfds);

        int result = select(gpsFd+1, &rfds, NULL, NULL, &tv);
        if (result > 0) {
            boost::mutex::scoped_lock(buffer_lock);

            if (read_buffer_pos == READ_BUFFER_SIZE) {
                syslog(LOG_WARNING,
                   "GPS read buffer reached maximum size; flushing it");
                read_buffer_pos = 0;
            }

            int r = read(gpsFd, read_buffer + read_buffer_pos,
                 READ_BUFFER_SIZE - read_buffer_pos);
            if (r > 0) {
                read_buffer_pos += r;
            }
            else if (r == -1) {
                syslog(LOG_NOTICE, "Read failed");
                // {disconnect}
                continue;
            }
            else if (r == 0) {
                syslog(LOG_NOTICE, "Remote client closed connection");
                // {disconnect}
                continue;
            }
        }
    }
}

void GpsdWrapper::parse_AS()
{
    // {block signals}

    while (true) {
        boost::this_thread::interruption_point();

        bool buffer_is_full;
        std::string buffer_copy;

        {
            boost::mutex::scoped_lock(buffer_lock);

            buffer_is_full = (read_buffer_pos == READ_BUFFER_SIZE);
            buffer_copy.assign(read_buffer, read_buffer_pos);
            read_buffer_pos = 0;
        }

        // {pass buffer_copy to a parser implementation}

        if (!buffer_is_full)
            usleep(300000);
    }
}

The idea here is that an instance of GpsdWrapper sits around in the calling scope, spawning two threads of its own to tick over eating/buffering data from a serial device and dispatching it to some parser, respectively. The parser has its own thread as we certainly don't want serial reads being delayed by any bottlenecks in the parsing process, and we can flush the shared buffer if such a bottleneck begins to cause a backlog of unparsed data, without causing problems on the source end.

Thread safety is allegedly guaranteed by constructing the scope-bound boost::mutex::scoped_lock objects, and all the buffer maths check out. But I was still seeing data dropping in the serial read at seemingly random intervals, implying a problem with the cursor read_buffer_pos.

It took a few hours of paid yet wasted office time to spot that my scoped_locks were in fact not scope-bound at all, because I forgot to give them names:

boost::mutex::scoped_lock(buffer_lock);
// ^ temporary object of type `scoped_lock`, lives only for the line

boost::mutex::scoped_lock l(buffer_lock);
// ^ named object with automatic storage and scope-bound lifetime

This silly little typo that I'd made identically in each case, went completely undetected and essentially meant that there would be no thread-safety in the entire mechanism.

Problem randomly found after a revitalising coffee break, I then set about trying to conjure up a way for the build process to catch mistakes like this in the future. But what would they be? GCC doesn't (and cannot be configured to) emit any warnings about this code because, in the general case, there's nothing wrong with a temporary object that is not assigned to anything and that thus dies straight away.

Indeed, even in the threading world you may use a lock as a waiting "gate" that can be safely released as soon as the gate has been passed. As it turns out, using block scope purely for the purpose of using block scope is more rare than common. Since we can't expect a toolchain to read our minds, it doesn't seem likely that we'll ever get an automated mechanism for identifying this possible error.

I guess the moral of the story is to remember this story when using scoped_locks.

Somehow I'd missed this unofficial teaser trailer for the BSG prequel "Blood & Chrome". It looks fantastic in most places (with slightly dodgy CGI sets in only a handful), although there's no way to gauge the quality of the plot, acting or writing at this stage.

The bad news, though, is that SyFy — who had upgraded the project from a 10-part webseries — has given up on it as a regular series and downgraded it back to its original format. I never saw the point in these 10-minute-per-episode "webisode" series, so this is incredibly disappointing.

However, it's hardly a surprise.

Sci-fi television has taken a complete battering on US TV over the last half-decade or so, with a myriad of high-quality shows — some bordering on staggeringly epic — left to rot in the annals of history because of "the way things are".

The way things are? How are things?

Things are that even if Joe "Sci-fi Fan" Bloggs watched his favourite shows religiously on his telly instead of downloading them online — often cited as a key factor in the lack of sci-fi TV success — it wouldn't make the blindest bit of difference… unless he's one of the 0.02% of US viewers with a Nielsen box.

The entire ratings system is a complete sham, yet it drives advertising and consequently series success. Which is… frustrating. Firefly & SGU in particular were staggeringly amazing, but this is not represented in these meaningless "viewing figures", so they get cut off. The network then develops the notion that Sci-Fi, which is expensive to produce, isn't going to make them any money in return (which, due to ratings driving advertising, is true) .. and suddenly nothing gets a decent run. Enterprise, Caprica, SG-1/SGA movies, now B&C not given the ground to grow and succeed because if the epic shows can't make it, then what chance do these good/potential shows have?

What we need is to take the Nielsen boxes away from the morons who watch "American Idol" and give them to people who watch actual TV. It's the only way. Otherwise the rest of us are simply doomed, with no chance of coming back from this TV abyss that intelligent or artistic people have fallen into. It breaks my heart but there it is.

When I win £140million in the EuroMillions I'll fund SGU and B&C myself. Must be able to get a couple of episodes out of that, right…?

I've pretty much made a home of Stack Overflow — the modern age's answer to Experts Exchange — over the last year and a bit. From arriving in January 2011, I swiftly began answering C++, PHP and jQuery questions and asked a few of my own. By yesterday, I'd accrued 53,733 reputation points, 6 gold badges, 62 silver badges and 132 bronze badges over 2,045 answers and around 30 of my own [all but one high-rated] questions. I consistently fell within the top 0.1% of users over a quarter by reputation points. I'd made hundreds of gnomish edits across the c++, php and jquery tags and posted more than a few fleeting bug reports and discussion threads on Meta Stack Overflow.

Exodus

Now, I'm not the first: sbi scaled back his contributions last year due to concern over the site's direction; Neil Butterworth and Roger Pate both ceased their activity too; other high-profile users whose names I've forgotten by now got tired of spending their energy on SO and threw in their hats. Even co-founder and super-admin Jeff Attwood left the site's parent company at the start of this month (though that likely had more to do with time and work constraints than much else).

So why did I do the same thing yesterday?

Stack Overflow is, on the surface of it, a great idea. On an saturated internet populated by hundreds of thousands of programmers and coders at all levels, it's difficult to find a forum of any kind whose signal-to-noise ratio isn't over the human safety threshold.

What do I mean by noise? I mean the low-quality, repetitive starter "questions" that post a block of poor code strung together from ten minutes reading an unauthoritative tutorial, asking "why doesn't this work?" No particular debugging effort has taken place, and the user in question would rather just "ask the internet" for "help" than set aside a few months to read a good, peer-reviewed book and properly learn the subject in question.

Here's where the problem lies; several, actually.

Problem 1: Laziness

I was recently witness to a teenager with a brand new tablet PC that needed to be configured get very frustrated when the work needed to configure it properly ended up taking more than a few minutes. Half an hour of software updates over a slow DSL line solved all the problems, but those thirty minutes had evidently been incredibly painful. The teenager had all but given up on the entire project after five minutes and, if it weren't for the fact that I was already on the job and had the tablet in my own hands, I'm sure it would have been shelved entirely for the day.

The information age seems to have bred laziness and entitlement into the latest generation. Why set aside time to properly learn something, when you've been brought up in a world where you can look up "facts" on Wikipedia in seconds? Of course, programming is about far more than just "facts": in fact, it's an art. And an art needs to be studied and learned.

Problem 2: Selfishness

Certainly everybody is entitled to their opinion, but mine is that there is a time and a place for everything, and if there is to be no place for quality, high-level discourse between mid-level and experienced programmers only for fear of offending the entry-level coders or sending them back to the web's advert-laden discussion forums, then that's a shame. This standpoint is still seen as "elitist" by many, but it's not.

Stack Overflow — for me, at least — started out as one of these places. After all, we say it's "not a forum" and that's not just because of its layout and posting mechanics. Inevitably, a successful programming Q&A gets famous enough to draw in anybody with a programming problem, because it's pretty much guaranteed that you'll get your programming problem solved in mere minutes if you post it on Stack Overflow.

But that's not what the site is. At least it's not what it used to be, it's not what I want it to be, and it's not what I think it should be. It's explicitly not www.debug-my-code-for-me.com: there's a question close vote reason called "too localised" for questions that wouldn't contribute to the site's archive of programming Q&A, and/or help anybody else at a later date. Dumping a link to a pastebin.com snippet and asking "why doesn't this work? solve my problem for me" clearly falls under that category.

Too many contributors now, though, are transfixed on the idea that "this site is here to help people" and that, as long as that goal is satisfied, that is enough. They jump on the "elitists" who disagree.

Problem 3: Expediency

But "help" is a very broad word. It's one thing to help somebody to learn and become a better programmer, and to learn something about a programming language; it's quite another to throw the code at them that fixes their problem, allowing them to skip — and never gain experience in — the critical steps of research and debugging. The IT industry needs more developers who know how to fend for themselves, who know how to use a debugger and who know how to apply their own critical thinking skills to solve a problem. These "helpers" are only doing the industry a disservice by encouraging this new lazy generation not to think any further than "I'll just tell Stack Overflow" when their 200-line program yields a segmentation fault.

My reaction

Ultimately, this is all just my opinion. I believe it staunchly and wholeheartedly, but it's just my opinion. It's one that seems to be shared by fewer and fewer of the contributors left on the site. It should be obvious that those spending the most time on the site would feel the most strongly about how their time is being used, and what the worth of the result really is. On a Stack Overflow that's flowing quickly away from the site that I believe it should be, I've been becoming more and more disillusioned about the hours that I spend adding to its value every day.

But, as a slightly obsessive Senior Software Developer, it's difficult to just leave a site. Since the start of last year it's been a core part of my daily routine; even after removing a button for it from my browser toolbar I'm still finding myself trying to click on it every ten minutes or so.

And, yes, the draw of gaining reputation — literally and figuratively — and in showing off technical accumen, as well as building up a portfolio of thousands of well-written technical explanations that might one day be shown to someone as some kind of proof of knowledge, cannot be ignored.

Consequently, I'd held on for a few extra months. But, having recently enjoyed a drawn-out debate with several people on the subject — including some over-zealous moderators — I've decided that it's just not worth it any more. It's a thankless job answering all those programming questions, and it's more thankless still having to try to explain myself every time I lightly berate a poster for not performing the most basic of critical thinking before posting (and such comments are usually upvoted several times before the nay-sayers step in).

So, I'm stepping out. I'd thought about deleting my account entirely but, as a natural hoarder, I couldn't bring myself to lose all that hard work. And who knows? Perhaps in a few months I'll give in and return to submit to more abuse for a few months, just for that occasional fleeting glimmer of glee at knowing that I've posted a top-quality explanation of some arcane technical limitation in one of the programming languages with which I am quite familiar. But, for the time being at least, I simply can't allow it all to get to me any more.

And if I have to re-configure my firewall to implement my choice not to do it any more (I do), then that's just how it is.

Bootnote

And, yes, I'm sure it's deliberately ironic that I made my blog typography imitate SO's.

And another bollocks post.

I don't think I'll be answering this one.