Two boys aged 2 and 4 months fill my days to capacity at the moment.

Keep on coding!

As primarily a C++ programmer, I used to shy away from code that contained this kind of black magic. However, unions are actually very cool things and are really not that scary or weird.

A union is basically a variable. But instead of being an int, or a float, or a double, a union can actually be any one of these things at a given point in time.

What? That doesn’t make any sense!

Wait – let me illustrate with an example.

The code below contains a union declaration at the top. Unions are declared just like structs, but instead of containing ALL the variables listed, a union only contains enough space for the largest one.

So in my example, where the union contains an int and a char – how big do you think will it be?

That’s right, it will be a single variable the same size as an int, because an int is larger than a char.

Storing and accessing union data is done just like it is with a struct:

#include <stdio.h>

int main()
{
    union ascii
    {
        int number;
        char symbol;
    } a;

    /* Incoming data - could come from a variety of sources: */

    a.symbol = 'x';
    a.number = 120; 

    /* output last type in (int) */
    printf("Variable a is set to %d\n", a.number);

    return 0;
}

Okaaay… but how do you know what it is when it can be multiple things?

Good question. You can’t actually tell what is inside a union, but the rule is that whatever you put in last, will be what you get out, and it is YOUR responsibility to remember what it was.

The best way to do this is with a variable that you update to contain the correct type (use an enum of INT, FLOAT, etc.)

If you access a union using a type that isn’t the same as the one last stored, what you get back is undefined.

Unions are really useful when you want to save storage space (especially good in embedded programming), or if you are receiving data that may arrive in different types (but which is essentially being used for the same purpose).

See? Not so scary after all.

However, there are a handful of compiled libraries too, so let’s take a very quick look at how we can use these. If you haven’t installed Boost, take a look at Boost in 3 Minutes to get you up and running.

1) Include the header of the library you are interested in using

I’m going to use the filesystem library:

#include <boost/filesystem.hpp>

Time taken: 30 seconds

2) Write some code using this library

Don’t forget to qualify the methods with a namespace (else it will not compile!)

#include <boost/filesystem.hpp>
#include <iostream>

int main()
{
    //don't forget this bit!
    using namespace boost::filesystem;

    path p("/var/log/dmesg");

    if (exists(p))
    {
        std::cout << p << " size is "
            << file_size(p) << std::endl;
    }

    return 0;
}

Time taken: 2 minutes

3) Compile your code with the boost libraries

Now, instead of just compiling our file, we have to include the filesystem library and let the compiler know where it lives:

g++ boost.cpp -I/usr/include/boost -lboost_filesystem -lboost_system

To clarify, the line above is made up of the following things:

Firstly I’ve passed the source code file to the compiler.

Secondly I’ve added the path to boost using the -I option.

Thirdly I’ve added the libraries I want to link to using -l.

In this case there are two libraries that I need to include, as the filesystem binary depends on the system binary. You will get a linker error if there are any dependencies when you include your initial library. This will tell you what else you might need to add.

Time taken: 30 seconds

The output of the little program above should be something like:

/var/log/dmesg size is 61318

And there you have it – boost compiled libraries in under 3 minutes :-)

For example, Boost contains libraries to help you with mathematical calculations, regular expressions, smart pointers and even python integration.

Parts of Boost have already been integrated into C++11, but if you (or your organisation) is not quite ready for C++11 yet, or you want to play with the other Boost libraries, you can get to grips with it really easily in just 3 minutes.

This guide covers the header only libraries (i.e. most of them). I’ll take a look at the compiled libraries next week.

1) Install Boost

As root/sudo type:

yum install boost-devel

You must install ‘boost-devel’, rather than just ‘boost’, or you will only get the compiled libraries and not the headers. Since boost is mostly header-only libraries, this won’t be much use!

Time taken: 30 seconds

2) Write yourself a program and Boost it!

In order to use the boost methods, you must include the namespace qualifier.

If you don’t, your compiler will tell you that the methods are undefined and you may end up on a wild goose chase trying to ensure that boost is installed correctly and that the header files are being found. Stop right there!

You can either include it in one line (as I have done here), or you can individually qualify each method you use, e.g. with boost::gregorian::.

//include the boost header file for the library you want to use
#include <boost/date_time/gregorian/gregorian.hpp>
#include <iostream>

int main()
{
    //don't miss this out or it won't compile
    using namespace boost::gregorian;

    //construct a date object
    date xmas(2011,Dec,25);

    //print the day of the week
    std::cout << "Christmas 2011 falls on ";
    std::cout  << xmas.day_of_week() << std::endl;

    //add a (leap) year
    date_duration leapyr(366);
    xmas += leapyr;

    //print day of the week next year
    std::cout << "Christmas 2012 falls on ";
    std::cout << xmas.day_of_week() << std::endl;

    return 0;
}

Time taken: 2 minutes

3) Compile and run your program

g++ boost.cpp

The output should be:

Christmas 2011 falls on Sun
Christmas 2012 falls on Tue

Then sit back and feel very pleased with yourself.

Time taken: 30 seconds

If you thought that was fab and want to learn what else you can do, full documentation is available here.

Can’t argue with that!

However, sometimes it’s nice to know a little bit more about what yum is up to. Have you ever found yourself hunting all over your hard drive, trying to find exactly where yum has installed something?

Me too.

Well, if you do ever need to quiz yum, the following commands will allow you to gather all the knowledge you need on what your latest install has done.

As with pretty much everything on Linux, yum keeps a record of what it does. This record lives in:

/var/log/yum.log

So you could take a look in this file and see what packages were installed on what date.

But wait!

Yum itself has a history command, so you can also see this information in a much prettier way by typing:

yum history

And then using the ID in the left column to get more information about each record:

yum history info 24

Finally, and most importantly, what if you need to know where yum has installed all the files from your latest update?

Well, yum uses rpm for installation, so you can use it to query the package, like this:

rpm -ql eclipse-cdt

Which will give you a list of the full path to every file that was installed onto your computer for the package in question (I’ve used eclipse-cdt, but obviously you can ask it about anything you’ve installed).

Handy!

The story that still makes me shudder when I think about it. When it comes to all time, super-duper, public cock-ups, this one is almost the programming equivalent of Ratners.

Strictly speaking I wasn’t actually trying to program anything when it happened. I was trying to… Oh let’s just start from the beginning shall we?

The danger of embedded systems

Not long out of university, I was working on an embedded linux platform. The embedded OS was accessed via telnet from Linux desktop machines. At any one time your terminal window could be logged into your desktop, or into the embedded Linux platform (can you see where this is going?).

I was asked to help out a colleague who was having trouble getting his embedded system up and running for testing.

He pointed me to his machine in the lab and then disappeared, leaving me to it.

Straight away I could see that the embedded board he was using was in a mess. Files were missing or corrupt and it was basically unrecoverable.

There were several terminal windows open at the same time, so I was switching between them to check build version, firmware version and to access my own machine remotely. I downloaded the latest build from my machine and logged into the system to reinstall it.

At least, I thought I did.

I typed:

rm -rf /

to delete everything, so I could start the install from scratch^[1].

But as I pressed the return key, I realised I was using a terminal window on his desktop machine.

And I was logged in as root.

If I had to describe that moment using a movie scene, it would be this one^[2]:

I totally destroyed his filesystem. He came to me with a broken embedded board and ended up with no test system and no desktop computer either.

What did I do?

After I’d finished reeling from the massive, MASSIVE mistake I’d just made, I gathered myself together, went to find my poor victim and confessed.

And apologized.

A lot.

What happened?

He very graciously took it in his stride (good, since there was bugger all he could do about it), and seemed happy enough once I promised I would immediately reinstall his operating system AND fix the test system.

I could have done it all in secret, and feigned ignorance if he had asked where his local files had gone.

But I owned up, and it wasn’t as bad as I thought it would be.

And now I can laugh about it (just).

And of course, I have NEVER made the same mistake again.

[1] The command I used, for those of you that aren’t familiar with Linux, is the equivalent of selecting your hard drive and pressing the delete key.

[2] Jaws contains a classic example of the Dolly Zoom: that wonderfully abused effect where the background moves away while the actor appears to loom larger, usually accompanied by some tense string music.

I’ll share that wonderful event with you tomorrow (see how I’m craftily tempting you to come back and visit me again?). In the meantime, here’s my take on how you can learn from those moments you’d rather forget…

1. Acknowledge what you did wrong

Even in this day and age of tools that record everything, automated comments, log files and digital history, there are still programmers out there who won’t admit when they have made a mistake. This varies from the vague ‘I don’t know how that happened,’ to the more outrageous ‘It wasn’t me!’.

Programmers, more than any other professionals I know, are very protective of their work and hate to look like they don’t know what they are doing. Compounding this is the culture of schadenfreude in finding fault with peers, and the retelling of major errors over and over again, especially on team events and nights out: “hey dude, at least I’ve never checked in code with half an email to my wife pasted in the comment at the top, ha ha ha!”

These stories, that provide so much amusement to everyone listening (except the protagonist), are popular because they make us all feel that we aren’t the only ones that make mistakes. And you know what? That’s actually a good thing.

No one gets it right all the time, so why try and hide your errors? As embarrassing as they are, covering them up and trying to forget about them is counter-productive. Not only are you trying to fool others that you never get it wrong, you are also fooling yourself that you don’t need to improve, or take more care, or understand a tool better, or learn something new.

So next time you check in a source file and find you’ve accidentally left memory leaking all over the show, stand up and be proud to admit it. In fact, get in first and tell people what you’ve done. Throw your hands in the air and shout about it. Apologise to your manager for causing 15 crashes in the overnight test suite.

Be human and accept that the only errors computers make are the ones we tell them to make.

2. Understand why it was wrong

In some cases this is easy, but in others you need to really look at why you made the mistake in the first place. If you don’t really, truly understand exactly what the error is that you made, and why you made it, you can’t be sure that you won’t ever do it again.

Was it a lack of understanding in a particular area? Maybe you don’t fully appreciate the workings of the library you are using, or your knowledge of pointers is less than perfect, or you’ve never really worked with this particular language/algorithm/operating system.

Whatever it is, understand why. It could be as simple as the fact that you were rushing and trying to do too many things at once (focus, people – attention to detail is one of your biggest assets). Or it could be that you were making modifications to code using intuition rather than knowledge. (Oops. Guilty.)

Once you know exactly why you made a mistake, you are a very, very long way ahead of the person next to you that just sweeps it under the carpet and tries to forget about it.

3. Commit to improving

Here’s the hard bit. This is the step that won’t happen instantly and that won’t happen by itself either. You HAVE to make the effort to improve in the area in which you made the mistake.

Created a mind-boggling memory leak? Read up on malloc and free (or new and delete; pick your weapon and don’t get them mixed up). Got your iterators all over the place? Go back to basics with STL and learn what you were trying to do. Deleted an afternoon’s worth of code by accident? Get the manual out, google a tutorial, or read the help files and understand the tool you are working with.

Make the commitment to NEVER make that mistake again. But if you do, go back to step 1 ;-)

4. Look back and laugh (eventually)

It is very important to maintain a sense of humour about your mistakes. Going over things you have done wrong can destroy your confidence and leave you sitting in a corner, unwilling to contribute, failing to suggest ideas, refusing to raise your hand, and staying out of the debate.

Never let a big programming mistake, especially a publicly humiliating one (my story tomorrow!), take away your confidence or your desire for learning. Don’t give up.

If you admit your mistake, understand it, and improve your knowledge, then you will be able to forgive yourself.

And you might even end up as the one saying, “Hey dude, do you remember that time I checked in code with half an email to my wife pasted in the comment at the top, ha ha ha!”.

5. Be gracious when someone else makes a mistake (very important)

I’m not saying you can’t laugh at someone else’s coding misfortunes, or that you have to cuddle your colleagues and tell them it’s OK to mess up the overnight test suite.

What I am saying is don’t go overboard on the humiliation. We left a voodoo doll on the desk of a colleague that messed up a release build one evening (OK, that’s actually quite horrible). BUT we were nice about it. We rallied around and talked about the disasters we had caused, we supported his mistake by talking about our own.

Remember that you’re all in it together. Your team, however diverse and intelligent/incompetent they are, will ALL benefit if everyone approaches mistakes with the right mindset.

Admit.

Understand.

Learn.

Laugh.

Join in.

Easy, eh?

Allocation

In C++, if you want to allocate on the heap rather than the stack, you need to use the new operator.

Just like the C equivalents, the new operator returns a void* pointer to the block of memory that has been allocated.

There are two versions of new, the first returns a single item:

int* x;
x = new int;

The second, using square brackets, returns an array of items:

int* x;
x = new int[16];

Checking for success

C allocators return NULL and set errno when they fail, which you should explicitly check for.

In C++ however, an exception is thrown (bad_alloc). If you don’t have the code in place to catch the exception, your program will terminate.

You can force C++ to behave like C by passing the nothrow argument to new:

int* x;
x = new(nothrow) int;

Now new will behave like a C function and set x to NULL if it fails.

Of course, if you do this, you’ll remember check for a NULL value before using the pointer, won’t you?

Clearing up

Just like in C, you MUST remember to clear up after yourself when you’ve spent the afternoon happily declaring memory on the heap.

To do this, you need to call delete. There are two versions of delete that match the two versions of new:

//for single objects
delete x;

//for arrays
delete[] x;

What if you use the wrong one?

If you forget to use the brackets on an allocated array, you will only delete the first element. The others will remain inaccessible in memory, causing a memory leak. And you don’t want that to happen, do you?

If you use the bracketed version on a single object the behaviour is undefined. Which, if you’re unsure, means you can’t rely on the result to be anything you might expect :-)

Can you mix and match between new, malloc, delete and free?

No. Never do this!

First off, it’s just plain wrong to mix functionality from two separate languages (even though you can).

Second, new and delete are used in C++ because they call the constructor and destructor of an object respectively. The C equivalents, malloc and free do not do this.

So, if you create an object with malloc, any work done in the constructor will not happen.

Worse, if you free an object that was allocated with new (instead of using delete), the object’s destructor is not called. If your object uses memory dynamically and the destructor does the clearing up, then what will you have? Yes, a memory leak.

But that won’t happen to you now, because you’ve just read this, right? ;-)

Why would you want to use dynamic memory?

You might want to create a variable or object that persists beyond the scope of the function it is created in (i.e. to share it between functions). The only way to do this is to create it dynamically, and then remember to deallocate it at a later point. Alternatively, you might not know the size of something you are using until runtime (e.g. reading in a file), in which case the heap is a better place to store your data. Why? Because the size of the stack is limited and it may be too small for unknown data processed at runtime.

How do you dynamically allocate in C?

There are three functions for memory allocation (plus one for deallocation). Each allocator returns a void* to the memory that has been allocated, which can be cast to the appropriate type.

Let’s look at each in turn:

1. malloc

This is the most commonly used method. Simply pass in how big you want your memory to be (in bytes), and you get a pointer to that memory back. The memory is uninitialized. If it fails it returns NULL.

2. calloc

Instead of passing in a size, you tell calloc how many of a certain type of variable you are going to use. E.g. 10 ints, or 16 structs. The memory is initialized to zeros. If it fails it returns NULL.

3. realloc

This method resizes an existing block of memory and you can make your existing memory allocation bigger or smaller. It frees the existing block and returns a void* to the new block. If you pass in zero, it effectively frees the memory in question. If it fails it returns NULL (see the comments in the code below for why you should pay careful attention to how you use realloc).

And what do you do when you’re finished?

You call free, nice and easy, and your memory is released (although it is not “deleted” as such – the data may exist until something else overwrites it, or part of it, or until the program ends).

Note that calls to malloc, calloc and realloc set errno if they fail. You can find out how to use errno here!

Can I see an example?

Sure – here’s a little bit of code that uses all four methods so you can see them at work:

#include <stdlib.h>

#define BIG_NUMBER 1024
#define SMALL_NUMBER 16

struct msg
{
	int code;
	char message[BIG_NUMBER];
};

int main(void)
{
	char* buffer;
	struct msg* messagelist;

	/* Allocate some memory from the heap */
	buffer = (char*)malloc(BIG_NUMBER);
	if (buffer != NULL)
	{
		/* I can use the memory safely */
	}

	/* Reduce the size of the memory */
	char* smallbuffer = (char*)realloc(buffer, SMALL_NUMBER);
	if (smallbuffer != NULL)
	{
		/* I can use the memory safely */
	}

	/*******************************************
	 * NOTE: Look carefully at the realloc call above.
	 * If the call to realloc had failed and I had assigned
	 * it to the original buffer like so:
	 *     buffer = (char*)realloc(buffer, SMALL_NUMBER);
	 * then my buffer would have been set to NULL and I would
	 * not only lose access to the data that was stored
	 * there, but I'd create a memory leak too!
	 *******************************************/

	/* Allocate some memory from the heap */
	messagelist = (struct msg*)calloc(SMALL_NUMBER, sizeof(struct msg));
	if (messagelist != NULL)
	{
		/* I can use the memory safely */
	}

	/* Remember to clear up after myself */
	free(smallbuffer);
	free(messagelist);

	/* NOTE: I DON'T need to free the 'buffer' variable */
	/* because realloc already did it for me :-) */

	return EXIT_SUCCESS;
}

Doh.