antonym

Boost is an incredibly powerful collection of portable class libraries for C++. There are classes for such tasks as date/time manipulation, filesystem interfaces, networking, numerical programming, interprocess communication and much more.

The Boost documentation is substantial, but can still be daunting to new users. So this article is the first of a series on using Boost, starting with basic threading. It aims to provide an accessible introduction, with complete working examples.

When you buy a car, you get a warranty, these days typically for 3 years on a decent model. Provided you keep up the fluid levels and do a bit of scheduled preventative maintenance, you're covered. So if the car fails, something breaks, or generally doesn't work the way it should, the supplier will fix it - for free. After all, you've paid for the car, you have a reasonable expectation of performance, safety and reliability. And ensuring that happens is good customer service and good business. So why isn't the same applied to computers and software? (This is an old rant I never quite finished, and decided to publish now just for fun - and see if it sparks any reaction.)

When I was in high school, I got a new calculator - my first scientific calculator. It wasn't one of those fancy graphing calculators, nor was it programmable. But it did have lots of buttons and functions, and it was shiny. Excited by my new toy, I would use it for all sorts of things. I could evaluate complex equations in a flash! It was great! So, I started using it for everything, even for simple calculations that I used to "waste time" doing in my head. No more would I leave an answer in its boring 3π/2 form - I would evaluate it to 9 decimal places!

When you are developing a new piece of software, you typically first spend quite some time setting up your development environment. As you progress, your application becomes a very cozy inhabitant of this environment, a safe happy cocoon that has evolved as you make lots of small changes to the application or your system. What could possibly go wrong?

Writing “const-correct” code will improve the quality and maintainability of your code. It is especially important and useful when writing Object-Oriented code, as objects are often passed around as constant references. Properly declaring non-mutating methods as const allows you to safely call any const method on such a reference. It is part of good type-safe practice and good code hygiene. So how do we do it?

This blog is now powered by the wonderful MovableType, Open Source Edition, running on SliceHost.

Installation was painless, following the instructions on the main website. I used PostgreSQL, my favourite RDBMS, on the back-end. I got a basic site up very quickly, and chose one of the supplied templates to get started.

I fell into the trap of thinking that every blog entry had to be fascinating, amazing, new, whiter, brighter and generally earth-shattering. But curiously I often read very popular blogs where people write about topics or techniques that I would consider obvious. And then one day it struck me - I was taking a great deal for granted.

In order to potentially double the readership of this blog from 2 to 4 people (Hi, Mom!) I've registered with Technorati, to see how that helps people find my site. You can visit my Technorati Profile and see for yourself. Note that there's only 1.1 Million blogs in my path as I skyrocket to the top!

Long ago, I was pointed to a most insightful post about coding culture at Microsoft (Bill's company) compared with Apple (Steve's company). They observed that at Microsoft, there is a tendency is to use trees as the preferred data structure. Trees are certainly convenient and appropriate for many underlying representations, and are generally easy to manipulate. At Apple, on the other hand, there is a tendency to use hash tables.

Trees tend to impose a hierarchy, enforcing a one-to-many structure (regardless of natural relationships). Hash tables are a looser form of association, which don't necessarily impose structure. This distinction tends to reflect a subtle but significant difference in the underlying philosophy and approach to problem solving and architecture.

No, I'm not talking about lazy Winter evenings on a rug... I'm talking about the responsibility of journalists to investigate, analyse, ask difficult questions, and cut through the hype and hyperbole.

So when a Senior Editor of eWeek sits down with a Microsoft SVP to discuss the recent deal with Novell, you would expect some thorough Q&A on this highly significant development. Instead, you get what reads like softball questions and slick pre-prepared answers.