List<foo> list = new List<foo>();
// .. do some stuff
Foo f = list.Find(delegate(Foo f) { return foo.Name == "Bar"; });

Straight away I fired back with an update to the code which used lambda expressions instead, as I'm a fan of how concise they are

List<foo> list = new List<foo>();
// .. do some stuff
Foo f = list.Find(foo => foo.Name == "Bar");

My friend ran this code against a data set that he had constructed and found that when the call to Find() was made, a NullReferenceException was being thrown. I found this odd as I hadn't seen that before. list was definitely a valid reference and the lambda expression was well-formed as well. So what was wrong?

It turns out that even though list was a valid reference, it didn't contain any elements.

How odd! Why would the generic List object throw an exception when the user calls Find() when no elements are present? After a little bit of thinking I thought that I had the answer. I thought to myself:

What if the List was a container for a value-type, such as int? If you attempt to find a value in an empty list, then the function cannot return null because that isn't valid for value-types! Throwing an exception does make sense!

Isn't it amazing how easy it is to convince yourself of your own greatness? I thought I'd nailed it first go. So I proposed my argument to my friend, who initially was semi-sold on the idea.

Then I thought about it again and managed to convince myself that my apparent "brilliance" was, in fact, a failure. The perfect counter-argument to the above point is:

What happens when you have a List of ints which does contain elements and you attempt to search for a value that is not in the list?

It wasn't immediately obvious. So I tried something to see what would happen:

List<int> list = new List<int>(new int[] { 1, 2, 3 });
int i = list.Find(x => x > 3);
// ....

So what do you think the value of i is after those first two lines? Yes, you guessed it: Zero. Why? Well, duh, it's because default(T) for integers is Zero!

This is where little alarm bells started to ring in my head. I immediately whipped up an example where this would be considered bad:

List<int> list = new List<int>(new int[] { 0, 1, 2, 3 });
int i = list.Find(x => x > 3);
// ....

Again, i is Zero when this code is executed, but the result is very misleading. Zero is contained in the collection but doesn't match the predicate, yet Zero is returned because that's the default value for this value-type.

I thought this was a bit of a glaring hole in the design. So I went straight to the documentation and found this:

Important Note:

When searching a list containing value types, make sure the default value for the type does not satisfy the search predicate. Otherwise, there is no way to distinguish between a default value indicating that no match was found and a list element that happens to have the default value for the type. If the default value satisfies the search predicate, use the FindIndex method instead.

This was concerning for a couple of reasons. First of all, the designers have left it up to you to determine that this is the default behaviour. Yes I should be able to come to that conclusion myself, but I didn't until I got bitten So shut up! Secondly, you have to check your result value against your predicate again to be sure that it's not dodgey. For example:

List<int> list = new List<int>(new int[] { 0, 1, 2, 3 });
int i = list.Find(x => x > 3);
if(i > 3)
{
  // .. valid value, do stuff ..
}
else
{
  // .. no item found
}

Do you want to do that? I certainly don't. After a bit of back-and-forth with Jimbo, I thought that the best option for a generic List Find() function would be one that is akin to the good old C++ days. It would look something like this:

bool Find<t>(Predicate<t> predicate, ref T output);

This would mean that you could change your code to something like the following:

int i;
List<int> list = new List<int>(new int[] { 0, 1, 2, 3 });
if(list.Find(x => x > 3, ref i))
{
  // .. valid value, do stuff ..
}
else
{
  // .. no item found, or empty list!
}

Note how with this option you could easily support the case for empty lists at the same time. It would be helpful and meaningful. Only when the function returns true can you rely on the output parameter. It's very clear and caters for value-types and reference-types. It'd be easy to implement in an extension method as well. I'd prefer this solution over using FindIndex().

In case it's not obvious, this problem would no doubt exist in all functions on generic objects that attempt to return a single instance of T based on some form of predicate. FindLast() would be another example.

I'm very keen to know the reasons behind the original design decision. I'm sure that minds far greater than mine parsed that problem and came up with that solution, probably for a very good reason.

What do you guys think?

For those who are lazy, here is the particular snippet of code that caught my eye:

lock (this.GetType())
{
  // .. stuff ..
}

If you want to see more, head over there and read up. There are quite a few instances of the code listed above.

So why is this disturbing? If you're not sure of the answer, take a bit of time to go and read up on C#'s lock keyword. When you're done, ask yourself "what kind of object should I be using alongside the lock keyword?".

If the answer escapes you, then toodle over to this little doozy for a blow by blow account. I'll quote a rather gifted developer friend of mine (who for now shall remain anonymous) who summed up nicely one of the issues that could occur if the above code makes it into your code base:

This is terrible, terrible, terrible.

Good luck with the cross-appdomain deadlock which brings down prod and can't be diagnosed without 2 weeks behind windbg.

Soooo true.

Now that you know it's bad you might be wondering how a framework like CSLA managed to get polluted by it. Time to speculate!

You may have noticed that the article I linked above mentions that the practice of locking type objects was actually demonstrated/advocated on MSDN:

This is even done in MSDN sample, makuing it the holy grail.
.
.
Rico Mariani, performance architect for the Microsoft® .NET runtime and longtime
Microsoft developer, mentioned to Dr. GUI in an e-mail conversation recently that a
fairly common practice (and one that's, unfortunately, described in some of our
documentation right now, although we'll be fixing that) is actually quite problematic.

Note: Spelling mistakes and awful grammar in the quote above are, for once, not my fault.

I'm guessing that the author(s) of CSLA were reading up on some multithreading documentation on MSDN and came across a sample which demonstrated locking type objects as shown above. Since they were reading MSDN, the apparent Bible for all things .NET, they may have assumed that whatever they saw could be taken as Gospel.

Unfortunately, no resource is perfect. Not even MSDN.

This is where I have my gripe. The authors of any software should always critique all of the code they come across during the course of development. Whether they wrote it themselves, got it from MSDN, read it on a blog site while researching or saw it in a book written by the author of the language. NEVER EVER assume that the code you are reading is 100% sound.

If the authors had thought about the meaning of the lock statement and had an understanding of exactly what GetType() does (ie. always returns the same reference when called on the same type), then perhaps they might have figured out that using a lock on something that's accessible from any object in the process is a bad idea. It is opening the door for potential deadlocks if somebody else decides to do the same.

So I say again: do not assume that the code you get off the Internet is safe! Scrutinise it. Pull it to pieces. Understand it. Then, if all is safe and you're still comfortable with it, consider using it in your software. Don't assume that the author of the code knows what they're doing...

... unless it's me of course

Joseph Cooney of LearnWPF.com (and WPF MVP to the stars) has kicked off a Codeplex project targetting funky shaders for use with the new features of WPF that were included in SP1. Specifically, it's intended to be a collection of open source/free shaders that can be easily plugged into your WPF apps to make them look schmick (for more info, check this out).

It's an open source/community thing where everyone is encouraged to contribute. I'll be aiming to add as much as I can given the time constraints of work and family life. JC has already added 5 effects, and I've added my first, which was a simple Radial Blur shader.

This stuff really is fun, so check it out!

This is an issue when dealing with third-party libraries that are not signed. Sometimes you'll be lucky enough to be dealing with vendor that is happy to provide a set of signed assemblies, other times you won't. If your scenario fits the latter (as a recent one did for my colleagues and I), you need to sign the assemblies yourself. Here's how.

Note: delay signing is not covered in this article.

Scenario 1 - Foo and Bar

Foo is the component that you're building which has to be signed.
Bar is the third-party component that you're forced to use that isn't.

Grab Bar.dll and project along with Foo.dll and project to see a source sample.

You'll notice Foo has a .snk which is used to sign Foo.dll. When you attempt to compile Foo you get the following error message:

Assembly generation failed -- Referenced assembly 'Bar' does not have a strong name

We need to sign Bar in order for Foo to compile.

Step 1 - Disassemble Bar

We need to open a command prompt which has the .NET framework binaries in the PATH environment variable. The easiest way to do this is to open a Visual Studio command prompt (which is usually under the "Visual Studio Tools" subfolder of "Visual Studio 200X" in your programs menu). Change directory so that you're in the folder which contains Bar.dll.

Use ildasm.exe to disassemble the file using the /all and /out, like so:

C:\Foo\bin> ildasm /all /out=Bar.il Bar.dll

The result of the command is a new file, Bar.il, which contains a dissassembled listing of Bar.dll.

Step 2 - Rebuild and Sign Bar

We can now use ilasm to reassemble Bar.il back into Bar.dll, but at the same time specify a strong-name key to use to sign the resulting assembly. We pass in the value Foo.snk to the /key switch on the command line, like so:

C:\Foo\bin> ilasm /dll /key=Foo.snk Bar.il

Microsoft (R) .NET Framework IL Assembler.  Version 2.0.50727.1434
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembling 'Bar.il'  to DLL --> 'Bar.dll'
Source file is ANSI

Assembled method Bar.Bar::get_SecretMessage
Assembled method Bar.Bar::.ctor
Creating PE file

Emitting classes:
Class 1:        Bar.Bar

Emitting fields and methods:
Global
Class 1 Methods: 2;
Resolving local member refs: 1 -> 1 defs, 0 refs, 0 unresolved

Emitting events and properties:
Global
Class 1 Props: 1;
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully

Bar.dll is now signed! All we have to do is reopen Foo's project, remove the reference to Bar.dll, re-add the reference to the new signed assembly and rebuild. Sorted!

Scenario 2 - Foo, Bar and Baz

Foo is the component that you're building which has to be signed.
Bar is the third-party component that you're forced to use that isn't.
Baz is another third-party component that is required in order for you to use Bar.

Grab Baz.dll and project, Bar.dll and project along with Foo.dll and project for a sample source.

When you attempt to build Foo you get the same error as you do in the previous scenario. Bear in mind that this time, both Bar.dll and Baz.dll need to be signed. So first of all, follow the steps in Scenario 1 for both Bar.dll and Baz.dll.

Done? OK. When you attempt to build Foo.dll after pointing the project at the new Bar.dll no compiler errors will be shown. Don't get too excited

When you attempt to use Foo.dll your world will come crashing down. The reason is because Bar.dll was originally built with a reference to an unsigned version of Baz.dll. Now that Baz.dll is signed we need to force Bar.dll to reference the signed version of Baz.dll.

Step 1 - Hack the Disassembled IL

Just like we did in the previous steps we need to disassemble the binary that we need to fix. This time, make sure you disassemble the new binary that you created in the previous step (this binary has been signed, and will contain the signature block for the strong name). Once Bar.il has been created using ildasm, open it up in a text editor.

Search for the reference to Baz -- this should be located a fair way down the file, somewhere near the top of the actual code listing, just after the comments. Here's what it looks like on my machine:

.assembly extern /*23000002*/ Baz
{
  .ver 1:0:0:0
}

This external assembly reference is missing the all-important public key token reference. Before we can add it, we need to know what the public key token is for Bar.dll. To determine this, we can use the sn.exe utility, like so:

C:\Foo\bin> sn -Tp Baz.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 3.5.21022.8
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key is
0024000004800000940000000602000000240000525341310004000001000100a59cd85e10658d
9229d54de16c69d0b53b31f60bb4404b86eb3b8804203aca9d65412a249dfb8e7b9869d09ce80b
0d9bdccd4943c0004c4e76b95fdcdbc6043765f51a1ee331fdd55ad25400d496808b792723fc76
dee74d3db67403572cddd530cadfa7fbdd974cef7700be93c00c81121d978a3398b07a9dc1077f
b331ca9c

Public key token is 2ed7bbec811020ec

Now we return to Bar.il and modify the assembly reference so that the public key token is specified. This is what it should look like after modification:

.assembly extern /*23000002*/ Baz
{
  .publickeytoken = (2E D7 BB EC 81 10 20 EC )
  .ver 1:0:0:0
}

Save your changes.

Step 2 - Reassemble Bar

This step is just a repeat of previous steps. We are again using ilasm to reassemble Bar.dll, but this time from the new "hacked" Bar.il file. We must use the exact same command line as we did previously, and we still need to specify the Foo.snk for signing the assembly. To save you having to scroll up, here it is again:

C:\Foo\bin> ilasm /dll /key=Foo.snk Bar.il

Microsoft (R) .NET Framework IL Assembler.  Version 2.0.50727.1434
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembling 'Bar.il'  to DLL --> 'Bar.dll'
Source file is ANSI

Assembled method Bar.Bar::get_SecretMessage
Assembled method Bar.Bar::.ctor
Creating PE file

Emitting classes:
Class 1:        Bar.Bar

Emitting fields and methods:
Global
Class 1 Fields: 1;      Methods: 2;
Resolving local member refs: 3 -> 3 defs, 0 refs, 0 unresolved

Emitting events and properties:
Global
Class 1 Props: 1;
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully

Open up Foo's project, remove and re-add the reference to Bar.dll, making sure you point to the new version that you just created. Foo.dll will not only build, but this time it will run!

Disclaimer

"Hacking" third-party binaries in this manner may breach the license agreement of those binaries. Please make sure that you are not breaking the license agreement before adopting this technique.

I hope this helps!

That's right folks, my angelic voice is now online for you all to experience. 8 minutes of Unity Build glory!

Get it here:

Setting up Unity Builds

I made the screencast using the demo version of Camtasia (which I give a big thumbs up to!). It weighs in at around 19MB in total, but it's well worth watching if you haven't seen a Unity Build in action before. Remember to check out The Magic of Unity Builds if you want some more technical information on how these builds work.

The project and associated source code that I used for this screencast is available for download right here.

As a final note, please forgive me for sounding tired!

I look forward to hearing your feedback. Enjoy!

How do you interact with your ViewState?

I've seen two methods in use in the various codebases that I've worked on. The first that I'll demonstrate is the most common form I've seen.

Let's pretend we have a web form which has a property called MyMagicValue which needs to be stored across postbacks.

Most developers would do something like this:

protected int MyMagicValue
{
    get
    {
        return (int)ViewState["MyMagicValue"];
    }
    set
    {
        ViewState["MyMagicValue"] = value;
    }
}

Information is stored directly in the ViewState hash/dictionary by accessing the ViewState property that exists on every web form/control. In this case there's a danger of things going horribly wrong "get" is invoked before "set"!

The second isn't so common. In fact, the only times I've seen it in a codebase is when I've implemented it myself. This leads me to believe that most of the time developers don't even know that this method exists. Here's the code:

private int _myMagicValue;
 
protected int MyMagicValue
{
    get
    {
        return _myMagicValue;
    }
    set
    {
        _myMagicValue = value;
    }
}
 
protected override object SaveViewState()
{
    object[] state = new object[2];
    state[0] = _myMagicValue;
    state[1] = base.SaveViewState();
 
    return state;
}
 
protected override void LoadViewState(object savedState)
{
    if (savedState != null)
    {
        object[] state = (object[])savedState;
 
        if (state.Length > 0)
        {
            _myMagicValue = (int)state[0];
            base.LoadViewState(state[1]);
        }
    }
}

Quite a bit different from the first version. But which one is better? Which is considered best practice? Which has the better performance?

I haven't done any extensive research into this topic other than chatting to a workmate or two. So I wouldn't say that I have hard data to back up what I'm about to say.

It seems to me that the latter implementation is preferrable for the following reasons:

1. Your page/control contains the usual definitions for container variables, just like most other classes without references to ViewState in every property definition.
2. You're not spreading references to ViewState all through your code.
3. You're not indexing into the ViewState hash for every since get/set for a given property.
4. If you want to add something else to the ViewState you can easily add it in the two overridden functions without affecting other areas of the code.
5. You don't have to worry about checking for null in the getters.
6. You could easily rip out the implementation and store in another class without a great deal of refactoring or code modification.

The former is preferrable to many coders because:

1. It's less code to write.
2. They don't know that the latter method exists.

So what's the verdict? Which of these is better, or considered "best practice"?

Edit: As per my comment below about using System.Web.UI.Pair, I thought I would add an example of how this should be used. It's not overly pretty when you get more and more values to store, but I still prefer it to directly manipulating the ViewState object.

protected override object SaveViewState()
{
    return new Pair(base.SaveViewState(), _myMagicValue);
}
 
protected override void LoadViewState(object savedState)
{
    if (savedState != null)
    {
        Pair state = savedState as Pair;
        if(state != null)
        {
            base.LoadViewState(state.First);
            _myMagicValue = (int)state.Second;
        }
    }
}

This doesn't look so bad with just a single value, but for each value you add to the ViewState you need another Pair instance.

In many colleges and univerties C++ is no longer taught as a core subject (along with Assembly language) which I find quite galling. It's a great language to learn, even if you never use it again. But the purpose of this post is not to preach the virtues and failures of the C++ language, but instead to talk about something that might aid those people who are using C++.

Anyone who's worked on a large C++ (or C) application has felt the pain of long build times. The first "big" C++ system that I worked on took 10 minutes to build. This was much bigger than anything I had experienced up until that point. Later in my career when I joined the games industry I really felt the pain of rebuilding a massive code base. The game took just under an hour to build from start to finish without any distributed compiling mechanism in place. When I finally got a copy of Incredibuild the build time dropped noticably, but not to a point where recompilation was an option every time I wanted it.

The solution that we implement: Unity builds (which I'll refer to as UB from now on because I'm lazy).

Now, a lot of C and C++ that have used these before might consider the idea of a UB to be a bit of a hack. I'm not sure if I agree or disagree. There is an air of "hackyness" about it, but it solves the problem of huge compile times on most platforms with most compilers.

Before I go into the definition, and give instructions on how to set up a UB, let me just state for the record that this isn't designed to replace normal builds for releasing code. The idea behind these is to dramatically reduce the build times for developers who are spending 8 hours a day modifying the code. Fixing bugs and adding enhancements generally means that a developer is constantly recompiling. Every time you compile, you have to wait (or perhaps entertain yourself in some way), and in waiting you are wasting precious time. Wasting time means a reduction in productivity. This can only be a bad thing. It's bad enough with short build times, but with long build times it becomes a huge problem. So please bear in mind that the normal release and product builds, builds that happen on automated build servers, etc, do not need to have a UB in place, they can continue to use normal builds.

The principle behind a UB is quite simple. It's all about reducing...

1. ... the number of times a file is opened.
2. ... the number of files that are opened.

In esssence, we're going to abuse the power of the preprocessor to do the above.

Every source file (.c, .cxx, .cc, .cpp, etc) that is compiled results in the creation of an object file. When all of the source files are compiled into object files, the linker then collects up all these object files and links them together into an executable application. For those of you who don't know: reading/writing to/from disk is the slowest thing you can do on a computer. Actually, it isn't so much the reading and writing, it's more the seeking. But the point remains the same. Disks are the only core parts of your system that have moving parts, so they're going to be slow! So if you want to speed things up, a good place to start is reducing I/O.

I don't want to turn this into a lesson on how C and C++ programs are compiled, so I'm going to cut to the chase. We know that the preprocessor parses each file before it's compiled which means that each file is going to be opened. When those parsed source files are then compiled, they're essentially opened again. Each of those files requires another seek. When the object file is generated, that's another seek. When the file is linked, that's another seek. There's lots of disk activity going on here!

If you haven't caught on yet, let me give you another hint. Each source file results in a couple of new files and a stack of seeks. We also have a neat preprocessor statement at our disposal (*cough* include *cough*).

That's right guys, we don't actually compile every file individually. We instead create a master file (or set of master files, depending on how big your source base is), which includes all of the other source files. This file (or set of files) is compiled instead.

To make it clear I'm going to show you the principle in action on a fake project in Visual Studio 2008. However, the principle can be applied regardless of the compiler and platform. Check out the screenshot on the left. This shows a standard C++ with a few files in it. Ordinarily each of those files will be compiled individually, and hence slowly.

The first step in creating a UB is to make a new project configuration which you can play with. Doing so will allow you to set up an area you can modify without breaking the "normal" project which will continue to be built as usual. So let's do that now. Create a new project configuration based on the debug build. See the following screenies:

When you've created the new configuration, make sure you have it set as the active configuration as shown on the right.

Then, you need to add a new file which will be the master UB file. I usually create a sub-folder in the project and add the file there. Both folder and file I tend to call UnityBuild.

When the file is created, the first thing we need to do is make sure that we edit the UnityBuild.cpp so that it includes all of the other files in the project. Check out the image for the example.

If we attempted to compile at this point, we have all kinds of issues. Everything right now is being included twice. So we need to fix that so that we don't have issues in every configuration. Let's start by fixing up the Unity build project. Select all of the source files except UnityBuild.cpp, and exclude them from the project (right-click on them to see the properties). Check out the pics below to see how it's done.

So that this point you've excluded the files from the UnityDebug configuration, and hence the unity configuration should build.

Note: if you're implementing this in a large existing source base you may find that the UB doesn't actually compile. You need to bear in mind that the preprocessor is making one large file out of all of your source files. Which means global variables, static variables, global functions, etc that appear more than once in the source code will now tread all over each other. Technically you shouldn't have this problem if you're writing "proper" code But the harsh reality is that lots of devs copy and paste code, duplicate function names, and all kinds of other horrible things. To get it working, you're going to have to do a bit of housekeeping! But since this is going to affect the source in a positive way, it can only be a good thing!

OK, next up let's get the other builds working again. You need to exclude the UnityBuild.cpp file from the build in both the Debug and Release builds (not the UnityDebug configuration). I won't show you how to do that, as it should be obvious. When you're done, you should see similar to the image on the left when you use the Debug or Release configurations from this point on.

You're done! The old builds should work just fine because your UB file isn't included in the configuration. Once you've sorted out the code duplication issues with the UB configuration, you should have a perfectly working configuration.

You may find that the whole process is much easier if you're building from the command line, especially using make on *nix machines, as you don't have to worry about excluding things from configurations. Instead, you just simply need to pass in a single file to the compiler - the UB file!

So after all that, what kind of improvements should expect to find? Well let me give you a few stats. When the UB was implemented at the game company I worked for, the build time dropped from 55 minutes to just over 6 minutes. When I implemented UB in a previous job the build time dropped from 10 minutes to less than 3 minutes. When I put them in place at home the build times dropped on average by 60%.

I'd be very surprised if you didn't notice a huge improvement in your build times if you use this mechanism.

Before I finish up, I need to highlight a few issues around housekeeping. As already stated, these builds are not used to replace the normal compilations. They should sit alongside to make it faster for the developer to do his or her work. This means that you need to make sure that both types of builds are working all the time. Keep your automatic builds using the normal build type, and you'll soon find out if you've not been maintaining your configurations properly.

Make sure that every time you add a new source file you exclude it from the UB configuration, and that you add it to the content of the UnityBuild.cpp file otherwise it won't be compiled and included in the build properly.

On the whole, UBs have really improved the speed in which I've been able to do things. My wait time for compilations is generally a third of what it was. That, in my view, is worth the "hack"

Thanks for reading!

PS. Please let me know of any typos, grammar errors, etc. It was a hefty post to put together and I might have missed a couple of obvious stuff-ups!

EDIT: I have fixed up a few grammar and spelling errors. Thank you Yoann and Bryce

void *mcRealloc( void *P, int SIZE )
{
  int oldSize = _msize( P );
 
  P = realloc( P, SIZE );
 
  if ( P )
  {
    for ( int i = oldSize; i < SIZE; i++ )
    {
      ((char *) P)[i] = (char) rand();
    }
  }
 
  return P;
}
 
void *mcMalloc( int SIZE )
{
  void *P;
 
  P = malloc( SIZE );
 
  if ( P )
  {
    for ( int i = 0; i < SIZE; i++ )
    {
      ((char *) P)[i] = (char) rand();
    }
  }
 
  return P;
}

Is it just me, or is this a huge WTF?

And it's these cases which are the inspiration for this blog post.

Objects are not only good for encapsulation and making more readable/maintainable code. They can also be used to improve code safety. Rather than try and explain through words what I mean by 'code safety', let's work through a couple of examples.

Example 1: Data Integrity in a Multithreaded Application

Let's say that we're working on a multithreaded application. We have a set of data that is constantly read and written across the different threads. We obviously don't want to have different threads writing to the dataset at the same time, as this may cause all kinds of issues with the data's integrity. We want to put a mechanism in place to ensure that the data's integrity is never put at risk. We can do this simply by 'locking' the sections of code that perform the data writes via a synchronisation technique such as a critical section, a semaphore or a mutex. For the sake of this example, we'll use a critical section. We'll wrap it up in an object for easy use. Let's pretend that we have a C++ critical section class that looks like this:[source:cpp]class CriticalSection
{
public:
CriticalSection();
~CriticalSection();

bool Lock();
bool Unlock();

// ...
};[/source]
To use the critical section object, all we need to do is this:[source:cpp]CriticalSection importantDataLocker;
// ...
if( importantDataLocker.Lock() )
{
// do stuff to important data
// ...

importantDataLocker.Unlock();
}[/source]
Easy enough isn't it! We'll use this code in our data writer object, so that we can make sure that all of our threads are playing nicely while writing the data. During the course of our data writing, we might want to do some other processing that is not related to writing data. Even though this task isn't related to writing the data out, we still retain the lock so that we can finish off the job after without having to unlock and relock. So we may have some code that looks like this:
[source:cpp]bool DataWriter::WriteFunkyData( FunkyData* data )
{
if( m_dataLocker.Lock() )
{
WriteABitOfData( data );
DoSomeProcessing( data );
WriteSomeMoreData( data );
// ...
m_dataLocker.Unlock();
return true;
}
return false;
}[/source]
Not really rocket science is it? The above code makes sure that all the code between Lock() and Unlock() is only run when no other threads are requesting a lock (or own a lock) on the critical section.

Unfortunately we have a problem. In a non-perfect world (like the one we live in) there's always a chance that somewhere between the call to Lock() and the call to Unlock() an error might occur. An exception may be thrown. The code might just return;. If that's the case, the critical section will not be unlocked because the Unlock() function won't be called before the function finishes.

The result? A critical section that's permanently locked, and all future Lock() requests will either hang or fail. This is not ideal. If we were using system-wide mutexes we'd do some serious damage! Cleary this isn't acceptable.

Most procedural programmers will adjust the code in the following manner:
[source:cpp]bool DataWriter::WriteFunkyData( FunkyData* data )
{
if( m_dataLocker.Lock() )
{
if( !WriteABitOfData( data ) )
{
m_dataLocker.Unlock();
return false;
}

try
{
DoSomeProcessing( data );
}
catch(...)
{
m_dataLocker.Unlock();
return false;
}

if( !WriteSomeMoreData( data ) )
{
m_dataLocker.Unlock();
return false;
}
// ...
m_dataLocker.Unlock();
return true;
}
return false;
}[/source]
Some of you might be laughing at the above code. And rightly so! But don't think that it's uncommon because it's not. As you can imagine, the code gets bigger, nastier and tougher to maintain. As the function increases in size, code duplication increases and the chance of making mistakes increases. What if a new maintenance coder decides to early-out without unlocking? You're still stuck with the same problem.

Further use of object-orientation is what's required to solve this problem. Let's use and abuse a couple of the core features of objects: construction and destruction:

• When an object is instantiated, it's constructor is called.
• When an object is destroyed, it's destructor is called

For those of you who don't know, objects are destroyed in two ways:

1. When they go out of scope.
2. When they are deleted.

Each function in C++ has it's own scope. As soon as the function is finished, the scope is no longer valid and any local variables are cleaned up. This happens when ...

• ... program execution reaches the end of the function.
• ... a return statement is reached.
• ... a exception is thrown that is not caught.

If there was an object that was able to lock the critical section when it's constructed and unlock the same critical section when it's destroyed, we could use it to make sure that the critical section is unlocked regardless of the way in which the function is exited. That was a bit of a mouthful, so to demonstrate the point have a look at the following code:[source:cpp]class CriticalSectionLocker
{
public:
CriticalSectionLocker( CriticalSection& cs )
: m_criticalSection( cs )
{
m_isLocked = m_criticalSection.Lock();
}
~CriticalSectionLocker()
{
if( m_isLocked )
{
m_criticalSection.Unlock();
}
}
bool IsLocked()
{
return m_isLocked;
}
private:
bool m_isLocked;
CriticalSection& m_criticalSection;
};[/source]
If we use this object instead of the verbose and repetitive method shown above, our code would look like this:
[source:cpp]bool DataWriter::WriteFunkyData( FunkyData* data )
{
CriticalSectionLocker csl( m_dataLocker );
if( csl.IsLocked() )
{
if( !WriteABitOfData( data ) )
{
return false;
}

DoSomeProcessing( data );

if( !WriteSomeMoreData( data ) )
{
return false;
}
// ...
return true;
}

return false;
}[/source]
This code is substantially easier to maintain. As soon as csl goes out of scope, the critical section will be unlocked automatically via the destructor. This will happen on early-outs and when exceptions are thrown. Job done!

Example 2: Flag/Value Toggling

Developers have been known to write code which relies on object state to function differently. While this might not be considered 'best practice', it's fairly common out in the wild. There are times where a developer may want to temporarily toggle a flag, or change the value of a variable, and change it back before the rest of the code is run. Here's an example (it's not real-life, but it should give you the idea):[source:cpp]void Person::GotToParty( NightClub* nc )
{
if( !nc->AllowsEntry( this ) )
{
// temporarily pretend we're older
// so we can go clubbing!
int backupAge = m_Age;
m_Age = 25;

if( nc->AllowsEntry( this ) )
{
this->Party( nc, HARD_BUT_SUBTLE );
}

// best restore our age now
m_Age = backupAge;
}
else
{
this->Party( nc, HARD );
}
}[/source]
Don't laugh, we've all been there!

It should be obvious that the code above suffers from the same shortcomings as the previous example. It's not resiliant against early-outs or exceptions. A similar type of construct/destruct mechanism can be used to reset the original value of a variable in a much safer way. An example class might look like this:[source:cpp]template< typename T >
class ValueToggler
{
public:
ValueToggler( T& variableToToggle, T tempValue )
: m_toggleVar( variableToToggle ),
m_originalValue( variableToToggle )
{
m_toggleVar = tempValue;
}

~ValueToggler()
{
m_togglerVar = m_originalValue;
}
private:
T& m_toggleVar;
T m_originalValue;
};[/source]
The object above is templated so that it can be used with a variety of types (eg. int, double, float). Using an object such as this, the example program code would change to the following:[source:cpp]void Person::GotToParty( NightClub* nc )
{
if( !nc->AllowsEntry( this ) )
{
ValueToggler vt( m_Age, 25 );

if( nc->AllowsEntry( this ) )
{
this->Party( nc, HARD_BUT_SUBTLE );
}
}
else
{
this->Party( nc, HARD );
}
}[/source]
Again, the code is smaller and a lot more bulletproof. The value of m_Age will be restored no matter what happens inside the function.

Conclusion and Final Thoughts

The above samples should show you how easy it is to use objects to help you write more defensive code. Though some people (usually the procedural programmers ) would say that this kind of code is a hack, it's my view that they're wrong. The code is clear, easy to maintain, and very safe.

Disclaimer: The code above hasn't been compiled, so it may contain errors. The point of the post is to show you the idea behind using objects for safety. Ideal implementations are beyond the scope of the article.

Thoughts and feedback are always welcome.

Creating concrete data objects/classes is a good thing to do, as it reduces the probability of bugs, and crazy side-effects. It's also an important first step in writing intuitive code - which will be the topic of a later blog post.

I'd like to quote one of my lecturers that I learned from during my time at UTS...

If in doubt, do as the ints do.

I realise the meaning of this point isn't obvious on the surface, but with some example code it'll all become clear.

An example concrete data type - a 3D Vector class

Let's say you're writing some code to do some 3D rendering, and you're in need of a class that can handle the functionality and behaviour of Vectors in 3D space. The first and most obvious thing that you need to handle are x, y and z coordinates. Let's start with a very basic Vector3 class:

class Vector3
{
public:
  float X;
  float Y;
  float Z;
};

At this point you've got an object that gives public access to its internal workings. Can we say that's what the int datatype does? Are you able to mess around with its inner workings? No, you're not. Not just that, but the idea of public member variables breaks the whole notion of encapsulation/information hiding. We need to hide the internal workings, but in doing so we remove the ability to set and get the values on the object. We need to expose some functions that will allow us to do that. Our improved version of the code might look like this:

class Vector3
{
private:
  // change the variable names to make it obvious that
  // they are member variables, not local or global.
  float m_X;
  float m_Y;
  float m_Z;
 
public:
  // getters
  float GetX();
  float GetY();
  float GetZ();
 
  // setters
  void SetX( float x );
  void SetY( float y );
  void SetZ( float z );
};

This is an improvement, as we now have control over the inner workings of the object without exposing the implementation to external classes. Now let's say that we want to be able to construct a new Vector3 object through a variety of ways, ie. in exactly the same way we can with int. For example:

// this is what we can do with ints:
int a( 1 );
int b = a;
int c( b );
int d, e;
d = e = c;
 
// we want do the same kind of things with our
// own class
Vector3 a( 1.0, 0.0, -1.0 );
Vector3 b = a;
Vector3 c( b );
Vector3 d, e;
d = e = c;

We need to expose some options for construction and assignment. So our next iteration might look like this:

class Vector3
{
private:
  // change the variable names to make it obvious that
  // they are member variables, not local or global.
  float m_X;
  float m_Y;
  float m_Z;
 
public:
  // construction - default to zero if nothing is passed in
  Vector3( float x = 0.0, float y = 0.0, float z = 0.0 );
  Vector3( Vector3& v );
 
  // assigment operator
  void operator=( Vector3& v );
 
  // getters
  float GetX();
  float GetY();
  float GetZ();
 
  // setters
  void SetX( float x );
  void SetY( float y );
  void SetZ( float z );
};

The above interface should do what we need it to... or should it? A more careful examination will reveal that it doesn't actually behave exactly as you'd expect. The copy constructor takes a reference to another Vector3, which could be modified inside the copy constructor. We have the same issue with our assignment operator. Integers do not behave this way, so we need to modify our interface a bit more to tidy it up:

class Vector3
{
private:
  // change the variable names to make it obvious that
  // they are member variables, not local or global.
  float m_X;
  float m_Y;
  float m_Z;
 
public:
  // construction - default to zero if nothing is passed in
  Vector3( float x = 0.0, float y = 0.0, float z = 0.0 );
  Vector3( const Vector3& v );
 
  // assigment operator
  void operator=( const Vector3& v );
 
  // getters
  float GetX();
  float GetY();
  float GetZ();
 
  // setters
  void SetX( float x );
  void SetY( float y );
  void SetZ( float z );
};

We've now made sure that the Vector3 class does not modify anything that doesn't belong to it, which again is how the integers behave. But there is still something missing. The assignment operator doesn't allow for chaining (eg. int a = b = c = d;) just like the ints do, so we need to make a slight adjustment to the overload:

// return a const reference to ourself
const Vector3& operator=( const Vector3& v );

There, much better.

We're now at the stage where we want to be able to add/subtract/multiply/divide vectors together, but before we start overloading the operators we should look at the way integers behave when they go through the same operations:

int a, b, c, d;
a = b; // b doesn't change, a does.
a * b; // both a and b do not change.
a = b * c; // both b and c do not change, but a does.
a = ( b + c ) * d; // a is the only thing that changes
a += b / c; // again, a is the only thing that changes.

It's obvious from this that when we overload the operators, we only modify the content of the object if it is on the left hand side of one of the assignment operators. Our interface should make this obvious:

class Vector3
{
private:
  // change the variable names to make it obvious that
  // they are member variables, not local or global.
  float m_X;
  float m_Y;
  float m_Z;
 
public:
  // construction - default to zero if nothing is passed in
  Vector3( float x = 0.0, float y = 0.0, float z = 0.0 );
  Vector3( const Vector3& v );
 
  // assigment operators - not const because the current object
  // needs to change
  const Vector3& operator=( const Vector3& v );
  const Vector3& operator+=( const Vector3& v );
  const Vector3& operator-=( const Vector3& v );
  const Vector3& operator*=( const Vector3& v );
  const Vector3& operator/=( const Vector3& v );
 
  // other operators - all const functions to make sure that the
  // internal state of the object doesn't get modified when the
  // function is called. Separate temporary instances of Vector3
  // objects are created and  returned when executed.
  Vector3 operator+( const Vector3& v ) const; // v1 + v2
  Vector3 operator-( const Vector3& v ) const; // v1 - v2
  Vector3 operator/( const Vector3& v ) const; // v1 * v2
  Vector3 operator*( const Vector3& v ) const; // v1 / v2
 
  // getters
  float GetX();
  float GetY();
  float GetZ();
 
  // setters
  void SetX( float x );
  void SetY( float y );
  void SetZ( float z );
};

The class is starting to take shape, but there are some other functions missing that are an integral part of any Vector class: normalise(), dot() and cross().

The normalise function is used to create a unit vector (ie. a vector with a length of 1.0). But the question here is: when calling the function, should the object be modified, or should it return a copy of the Vector with a unit length? Let's look at the difference in function signatures:

// this function would modify the object directly
void Normalise();
// this function would return a new vector that is normalised
Vector3 Normalise() const;

Making a decision like this can be a bit of a pain in the butt, but we're fortunate in this case because we can deduce what should be done! Generally when dealing with normalised vectors, we tend to retain a reference to the normal while dealing with a stack of other vectors. So another instance of a vector is used alongside the other vectors. Let's look at how this might be done with both above functions if we had a vector that we wanted to reuse, but get a normalise version of at the same time:

// this is the vector we want to keep as is, but need a
// normalised copy of
Vector3 someVector;
 
// here's how we'd do it with the first option:
Vector3 normal1 = someVector;
normal1.Normalise();
 
// here's how we'd do it with the second option:
Vector3 normal2 = someVector.Normalise();

In my view, the second option is easier to read, and is a bit more intuitive. Not just that, but it's less code! So based on this, we'll utilise the second version of the function. Our class now looks like this:

class Vector3
{
private:
  // change the variable names to make it obvious that
  // they are member variables, not local or global.
  float m_X;
  float m_Y;
  float m_Z;
 
public:
  // construction - default to zero if nothing is passed in
  Vector3( float x = 0.0, float y = 0.0, float z = 0.0 );
  Vector3( const Vector3& v );
 
  // assigment operators - not const because the current object
  // needs to change
  const Vector3& operator=( const Vector3& v );
  const Vector3& operator+=( const Vector3& v );
  const Vector3& operator-=( const Vector3& v );
  const Vector3& operator*=( const Vector3& v );
  const Vector3& operator/=( const Vector3& v );
 
  // other operators - all const functions to make sure that the
  // internal state of the object doesn't get modified when the
  // function is called. Separate temporary instances of Vector3
  // objects are created and  returned when executed.
  Vector3 operator+( const Vector3& v ) const; // v1 + v2
  Vector3 operator-( const Vector3& v ) const; // v1 - v2
  Vector3 operator/( const Vector3& v ) const; // v1 * v2
  Vector3 operator*( const Vector3& v ) const; // v1 / v2
 
  // getters
  float GetX();
  float GetY();
  float GetZ();
 
  // setters
  void SetX( float x );
  void SetY( float y );
  void SetZ( float z );
 
  // helpers
  Vector3 Normalise() const;
};

So, next up we need the dot() function, which gives us the dot product of two vectors. The dot product is a single value which represents the angle between the two vectors, so that's what the function should return. Since the dot product requires two vectors, it would make sense for the function to be given a reference to the secont vector that is part of the dot product equation. None of the objects should be modified at all during the course of the function, so we should make that obvious in the function signature. Our class now looks like this:

class Vector3
{
private:
  // change the variable names to make it obvious that
  // they are member variables, not local or global.
  float m_X;
  float m_Y;
  float m_Z;
 
public:
  // construction - default to zero if nothing is passed in
  Vector3( float x = 0.0, float y = 0.0, float z = 0.0 );
  Vector3( const Vector3& v );
 
  // assigment operators - not const because the current object
  // needs to change
  const Vector3& operator=( const Vector3& v );
  const Vector3& operator+=( const Vector3& v );
  const Vector3& operator-=( const Vector3& v );
  const Vector3& operator*=( const Vector3& v );
  const Vector3& operator/=( const Vector3& v );
 
  // other operators - all const functions to make sure that the
  // internal state of the object doesn't get modified when the
  // function is called. Separate temporary instances of Vector3
  // objects are created and  returned when executed.
  Vector3 operator+( const Vector3& v ) const; // v1 + v2
  Vector3 operator-( const Vector3& v ) const; // v1 - v2
  Vector3 operator/( const Vector3& v ) const; // v1 * v2
  Vector3 operator*( const Vector3& v ) const; // v1 / v2
 
  // getters
  float GetX();
  float GetY();
  float GetZ();
 
  // setters
  void SetX( float x );
  void SetY( float y );
  void SetZ( float z );
 
  // helpers
  Vector3 Normalise() const;
  double Dot( const Vector3& v ) const;
};

Note that the function is marked as const to imply that the object will not have a different state when it's called, and the parameter is a const reference to imply that the parameter will not be modified as well.

Finally, we need a function which will determine the cross product of two vectors (commonly used to determine the vector that is perpendicular to two input vectors. The cross product equation takes two vectors and results in another vector, which again implies that the two input vectors do not change. Based on this implication, our function signature should be easy to deduce. While we're there, let's just chuck in a cheeky length() function which will give us the magnitude of the vector. Our class now looks like this:

class Vector3
{
private:
  // change the variable names to make it obvious that
  // they are member variables, not local or global.
  float m_X;
  float m_Y;
  float m_Z;
 
public:
  // construction - default to zero if nothing is passed in
  Vector3( float x = 0.0, float y = 0.0, float z = 0.0 );
  Vector3( const Vector3& v );
 
  // assigment operators - not const because the current object
  // needs to change
  const Vector3& operator=( const Vector3& v );
  const Vector3& operator+=( const Vector3& v );
  const Vector3& operator-=( const Vector3& v );
  const Vector3& operator*=( const Vector3& v );
  const Vector3& operator/=( const Vector3& v );
 
  // other operators - all const functions to make sure that the
  // internal state of the object doesn't get modified when the
  // function is called. Separate temporary instances of Vector3
  // objects are created and  returned when executed.
  Vector3 operator+( const Vector3& v ) const; // v1 + v2
  Vector3 operator-( const Vector3& v ) const; // v1 - v2
  Vector3 operator/( const Vector3& v ) const; // v1 * v2
  Vector3 operator*( const Vector3& v ) const; // v1 / v2
 
  // getters
  float GetX();
  float GetY();
  float GetZ();
 
  // setters
  void SetX( float x );
  void SetY( float y );
  void SetZ( float z );
 
  // helpers
  Vector3 Normalise() const;
  double Dot( const Vector3& v ) const;
  double Length() const;
  Vector3 Cross( const Vector3& v ) const;
};

The interface to our class now looks fine.. except for one small omission. Const objects are read-only objects, and hence reading values from a const object should be legal. On the flip side, when we read a given x, y, or z value from a vector the vector shouldn't be modified at all. So with that in mind, we should mark each of the getter function as const as well:

class Vector3
{
private:
  // change the variable names to make it obvious that
  // they are member variables, not local or global.
  float m_X;
  float m_Y;
  float m_Z;
 
public:
  // construction - default to zero if nothing is passed in
  Vector3( float x = 0.0, float y = 0.0, float z = 0.0 );
  Vector3( const Vector3& v );
 
  // assigment operators - not const because the current object
  // needs to change
  const Vector3& operator=( const Vector3& v );
  const Vector3& operator+=( const Vector3& v );
  const Vector3& operator-=( const Vector3& v );
  const Vector3& operator*=( const Vector3& v );
  const Vector3& operator/=( const Vector3& v );
 
  // other operators - all const functions to make sure that the
  // internal state of the object doesn't get modified when the
  // function is called. Separate temporary instances of Vector3
  // objects are created and  returned when executed.
  Vector3 operator+( const Vector3& v ) const; // v1 + v2
  Vector3 operator-( const Vector3& v ) const; // v1 - v2
  Vector3 operator/( const Vector3& v ) const; // v1 * v2
  Vector3 operator*( const Vector3& v ) const; // v1 / v2
 
  // getters
  float GetX() const;
  float GetY() const;
  float GetZ() const;
 
  // setters
  void SetX( float x );
  void SetY( float y );
  void SetZ( float z );
 
  // helpers
  Vector3 Normalise() const;
  double Dot( const Vector3& v ) const;
  double Length() const;
  Vector3 Cross( const Vector3& v ) const;
};

We're done! Our class looks complete (enough), so let's pump out a definition for the functions (just for the sake of clarity).

Vector3::Vector3( float x, float y, float z )
: m_X( x ),
  m_Y( y ),
  m_Z( z )
{
  // don't need to do anything in the body of the
  // function because we're using the initialisation
  // lists instaed.
}
 
Vector3::Vector3( const Vector3& v )
: m_X( v.m_X ),
  m_Y( v.m_Y ),
  m_Z( v.m_Z )
{
  // don't need to do anything in the body of the
  // function because we're using the initialisation
  // lists instaed.
}
 
const Vector3& Vector3::operator=( const Vector3& v )
{
  // check for self-assignment
  if( this != &v )
  {
    m_X = v.m_X;
    m_Y = v.m_Y;
    m_Z = v.m_Z;
  }
 
  // return a reference to ourselves for chaining
  return *this;
}
 
const Vector3& Vector3::operator+=( const Vector3& v )
{
  m_X += v.m_X;
  m_Y += v.m_Y;
  m_Z += v.m_Z;
 
  return *this;
}
 
const Vector3& Vector3::operator-=( const Vector3& v )
{
  m_X -= v.m_X;
  m_Y -= v.m_Y;
  m_Z -= v.m_Z;
 
  return *this;
}
 
const Vector3& Vector3::operator*=( const Vector3& v )
{
  m_X *= v.m_X;
  m_Y *= v.m_Y;
  m_Z *= v.m_Z;
 
  return *this;
}
 
const Vector3& Vector3::operator/=( const Vector3& v )
{
  m_X /= v.m_X;
  m_Y /= v.m_Y;
  m_Z /= v.m_Z;
 
  return *this;
}
 
Vector3 Vector3::operator+( const Vector3& v ) const
{
  return Vector3( m_X + v.m_X, m_Y + v.m_Y, m_Z + v.m_Z );
}
 
Vector3 Vector3::operator-( const Vector3& v ) const
{
  return Vector3( m_X - v.m_X, m_Y - v.m_Y, m_Z - v.m_Z );
}
 
Vector3 Vector3::operator/( const Vector3& v ) const
{
  return Vector3( m_X / v.m_X, m_Y / v.m_Y, m_Z / v.m_Z );
}
 
Vector3 Vector3::operator*( const Vector3& v ) const
{
  return Vector3( m_X * v.m_X, m_Y * v.m_Y, m_Z * v.m_Z );
}
 
float Vector3::GetX() const
{
  return m_X;
}
 
float Vector3::GetY() const
{
  return m_Y;
}
 
float Vector3::GetZ() const
{
  return m_Z;
}
 
void Vector3::SetX( float x )
{
  m_X = x;
}
 
void Vector3::SetY( float y )
{
  m_Y = y;
}
 
void Vector3::SetZ( float z )
{
  m_Z = z;
}
 
Vector3 Vector3::Normalise() const
{
  double length = Length();
  if( length == 0.0 )
  {
    // return a zero vector if it's got zero length
    return Vector3();
  }
  double invLength = 1.0 / length;
  return Vector3( m_X * invLength, m_Y * invLength, m_Z * invLength );
}
 
double Vector3::Dot( const Vector3& v ) const
{
  return  m_X * v.m_X + m_Y * v.m_Y + mZ * v.mZ;
}
 
double Vector3::Length() const
{
  return sqrt( m_X * m_X + m_Y * m_Y + mZ * mZ );
}
 
Vector3 Vector3::Cross( const Vector3& v ) const
{
  return Vector3( m_Y * v.m_Z - m_Z * v.m_Y,
                  m_Z * v.m_X - m_X * v.m_Z,
                  m_X * v.m_Y - m_Y * v.m_X );
}

Now that we have a functional class, we should have no problem using it in all of the above scenarios without any crazy side-effects. The class should be concrete!

Disclaimer: This code hasn't been compiled, and might not run without a few tweaks. I wrote this off the top of my head while sitting in front of the TV! Comments, questions and flames are welcome.