Static asserts

One of the new features of C++11 is the ability to do a compile-time assertions. These assert functions are similar in concept to the runtime assert functions we all know and love. You pass in a constant expression and a string; if the expression does not evaluate to true, then the compiler generates an error message from the string. For instance:

// Make sure we only compile this code for 64-bit platforms
static_assert( sizeof( long ) == 8, "This code requires a 64-bit compiler" );


The first thing to recognize about the static_assert is that the expression must be a constant expression. If you think about it, this makes sense. In order for the compiler to be able to generate the diagnostic, the compiler must be able to figure out at compile time whether the expression will be true or false. But it still takes a bit of cognitive effort to remember to use constant expressions when you first start using static_asserts.

Why would you ever use a static_assert though? It depends entirely on what you consider to be acceptable in your code base, and what you want to let slide. For instance, let’s say you are writing some cross-platform code that uses threads and you’ve chosen to use the pthreads library. You can do one of three things: you can either use #if code around all of the pthread-specific code, you can just assume pthreads will always be available and if it’s not there will be a lot of compile errors, or you can use static_assert to generate a sensible compile error if pthreads aren’t available.

#ifndef _POSIX_THREADS
static_assert( false, "The pthreads library is not defined, so none of this code will compile properly." );
#endif

Obviously, any one of these methods will work just fine — it all boils down to choice. The static_assert gives you more control in that you’re effectively allowed to generate your own compile errors without relying on compiler-specific pragmas or preprocessor extensions.

One interesting thing to note is that the static_assert will work with the new constexpr declarations (assuming your compiler supports them). So, another way we could have written the example above is:

static constexpr bool ArePThreadsAvailable() {
#ifdef _POSIX_THREADS
  return true;
#else
  return false;
#endif
}

static_assert( ArePThreadsAvailable(), "The pthreads library is not defined, so none of this code will compile properly." );

Are static_asserts the best thing since sliced bread? Not really. But they are a handy construct to pull out when you want to have a clean error message when compiling. I can imagine using this to ensure an x86 compiler (due to use of assembly language), or to ensure specific libraries are available, to ensure people have properly defined preprocessor macros for my library, etc. I’m sure there are plenty of other uses as well.

This entry was posted in C/C++ and tagged , . Bookmark the permalink.

1 Response to Static asserts

  1. Dan says:

    Big YES here.

    I’ve used “homegrown” versions “static_assert” for years in my C and my C++ code — basically pre-processor tricks that eventually result in declaring an array of size -1 (“negative one”) when the expected condition is false. This leads to a compile-time error message, but it’s not nearly as clean/standard/elegant as the new built-in C++11 static_assert.

    I use them a lot. Since I work on a variety of embedded systems, often things like data type sizes, library availability, etc. vary from platform to platform. Catching as much as possible at compile time is a huge win.

Leave a Reply

Your email address will not be published. Required fields are marked *