antonym

During a code review at work recently, we had an interesting discussion about code maintenance. You could say that coding is a bit like gardening: while you are planting new seedlings, do you weed nearby areas as you go, or save up all the weeding for the next sunny weekend? Should code maintenance be a continual, gradual process, or does it warrant being scheduled as a task in its own right?

I recently read an interesting article by Andy Jeffries entitled 25 Tips for Intermediate Git Users (linked to via proggit) . It had lots of useful information condensed into bite-sized task-oriented chunks.

I've been using Mercurial for a while now, so I thought I would write a similar set of tips by translating from git to the equivalent hg commands. Thanks to Andy for blessing this translation work. There may well be some mistakes herein - please leave a comment if you have any improvements or fixes to suggest.

In Part I of this series on Boost, we looked at the basics of how to create and run threads using the Boost libraries. But once you have more than one thread running in a process, you have to deal with the problems and challenges that threads can introduce. So, before delving into the mechanics of how to use mutexes and other threading constructs, we look at what can go wrong - and how to avoid it.

The STL makes it easy to create lists, iterate over lists, and apply a function to each member of a list. So how do you filter a vector according to some criteria? It's not hard, but the obvious solution isn't quite enough. Here's how.

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.