Tuesday, April 29, 2014

Unsigned integers considered annoying

Let's talk about unsigned integers. These can be tricky because they wrap-around from big to small. Signed integers wrap-around from positive to negative. Let's look at an example. Suppose I want to do something for all iterations of a loop except for the last OFFSET of them. I could write something like:

```  if (i < length - OFFSET) {}
```

If I assume OFFSET is 8 then for length 10, I'll do something for the first 2 iterations. The problem occurs when the length is less than OFFSET. If length is 2, then I'd expect not to do anything for any of the iterations. For a signed integer 2 minus 8 is -6 which is less than i, so I don't do anything. For an unsigned integer 2 minus 8 is 0xFFFFFFFA which is still greater than i. Hence we'll continue to do whatever it is we shouldn't be doing in this instance.

So the obvious fix for this is that for unsigned integers we do:

```  if (i + OFFSET < length) {}
```

This works over the range that we might expect it to work. Of course we have a problem with signed integers if length happens to be close to INT_MAX, at this point adding OFFSET to a large value of i may cause it to overflow and become a large negative number - which will continue to be less than length.

With unsigned ints we encounter this same problem at UINT_MAX where adding OFFSET to i could generate a small value, which is less than the boundary.

So in these cases we might want to write:

```  if (i < length - OFFSET) {}
```

Oh....

So basically to cover all the situations we might want to write something like:

```  if ( (length > OFFSET) && (i < length - OFFSET) ) {}
```

If this looks rather complex, then it's important to realise that we're handling a range check - and a range has upper and lower bounds. For signed integers zero - OFFSET is representable, so we can write:

```  if (i < length - OFFSET) {}
```

without worrying about wrap-around. However for unsigned integers we need to define both the left and right ends of the range. Hence the more complex expression.

Thursday, April 17, 2014

Interviewing Steve Clamage about C++11

The video of my interview with Steve Clamage about C++11 is now available. Steve is not only our C++ compiler lead, he's also the chair of the US C++ committee. What I particularly like about talking with Steve is that he always gives thoughtful and thought-provoking answers.

Wednesday, April 16, 2014

Lambda expressions in C++11

I had a bit of a shock when I first saw Lamdba Expressions in C++11. They use all three kinds of parentheses:

`[] () {}`

and bizarrely, that's also valid code. So perhaps you can understand why they are initially kind of hard to parse. However, once you start playing with them you realise that they are a useful, and powerful, extension to the C++ language. With this in mind, Steve Clamage (our C++ compiler lead) and I have put together a short paper introducing C++11 Lambda Expressions.

Friday, April 11, 2014

New map and set containers in the C++11 Standard Library

Steve Clamage and I have just written a short article on the std::unordered_map, std::unordered_set, std::multimap, and std::multiset containers in the C++ Standard Library.

Friday, April 4, 2014

Interview with Don Kretsch

This week I also got to interview the Senior Director of the Solaris Studio organisation, and discuss the 12.4 release. Been a busy week!

Code Analyzer interview

I've been doing something different. As well as looking at disassembly, I've been putting together some material to support the Solaris Studio 12.4 beta programme. The first of this material is an interview with Raj Prakash.

Raj is the project lead for the Code Analyzer - our suite for checking code correctness. The Code Analyzer does static and dynamic checking of applications for common coding errors. You can find out more from the video:

Video introduction to the Solaris Studio Beta

Here's a brief to-camera from me about the Solaris Studio 12.4 Beta programme.