Category Archives: C++

C++11 and “old” operating systems

We want to switch to C++11. It’s not just that it’s new and shiny, but it has a lot of features that will make for more readable code.

But… there’s runtime support involved in some of the C++11 features. So what to do about older operating systems that vendors aren’t supporting in their C++11 rollout? E.g. Apple is not supporting 10.6 with libc++.

FreeBSD has a new low-level library for the C++ standard called libcxxrt, which sits below libstdc++ (GNU) or libc++ (LLVM). It’s open-sourced, so maybe this would be one option, at least for Unix flavors like Mac OS X and Linux.

Interestingly, the claim is that if you link libstdc++ against libcxxrt instead of libsupc++ (the older low-level library), you can mix libraries that use libc++ with libraries that use libstdc++ in the same program. Now, of course, they have done this work for FreeBSD and not other operating systems, but maybe this can be repeated. It’s perhaps even likely, since Clang is gaining more and more momentum, and it’s moved ahead of GNU C++ in terms of C++11 support.

And Clang compiles my large programs much faster than gcc does.

std::optional in C++14

There’s a proposal to add optional (based on boost::optional) into C++14.

As a reference, here is Boost.Optional

Note that other languages have this, and it does come in handy (e.g. Perl has “defined”), but it has to be used carefully.

Why talk about this?

I have a use case for optional that is compelling.

I want to initialize something on first use, and then let multiple people use it, but not destroy it until after main AND after all users are done with it. This last bit is to prevent init, shutdown, init … shutdown if I have serial use. E.g. Windows Socket initialization – don’t want to call it unless someone is going to use networking code, but then I don’t want to call it multiple times if someone opens and closes sockets one after the other.

So with a shared_ptr as a global wrapped inside a Singleton pattern, I get most of that – I get to have ref-counting, and then the fact that it’s a global means I have a ref count maintained until after main. BUT – I get initialized at startup, which I don’t want. If my singleton contains a pointer to the resource, then I avoid init-at-startup, but now I either don’t have a shareable refcount, or I need some code at shutdown – which I can’t schedule properly.

But if I wrap my global as an optional, then I get both – I get C-level initialization, because an optional is so very close to a POD type that there’s no work needed for the constructor other than zero-initialization (which is guaranteed for global objects), and I have a destructor on the contained value once I initialize it.

I still dislike most of the use cases I’ve seen optional used for, but this one is something I’m going to use.

I was reading the C++14 proposal for optional, and I saw mention of value_or.


will pass optvar.value to process, if optvar is engaged (i.e. has a contained value), or it will pass 0. This would make a lot of the code I’ve seen more compact and readable.

Things are slightly different between C++03 and C++11. And I have to do some experiments to see if optional fits into C++03 zero-initialization rules or if it requires C++11 constant initialization rules. Since optional is really just a boolean and a raw array, it should be zero-initialized.



The Boost organization web page is

Boost 1.54 was released on July 1, 2013.

The Boost book is online at; this is the subset generated from BoostBook or QuickBook sources. The full documentation is found at:

Boost is still maintained in Subversion: The Trac wiki is:

There is a Git mirror of trunk and release branches on GitHub: There was a comment from Marshall Clow that Boost will move to Git at some point. There is a 6-month old page on the Subversion Trac talking about Git:

It looks like the “real” Boost-in-git link is It’s not a Subversion mirror, but it was mentioned in the boost mailing list, so I think this is going to be it. It looks like they are going towards the submodule approach. The main repository is and you recursively clone from there

git clone --recursive

Ten of the Boost libraries were released as part of TR1 in 2006, and then folded into C++11.

The big ones are bind and function, array, shared_ptr and weak_ptr, regex, type traits, random, tuple, hash, unordered_set and unordered_map. Pete Becker wrote a very good book on TR1 titled “The C++ Standard Library Extensions”, and the latest version of Stroustroup’s The C++ Programming Language covers C++11 as a whole.



Working with macros in C/C++

Macros are a long-standing double-edged sword. They are hard to work with safely, but useful in certain cases. More importantly, even if you eschew macros in your code, lots of third-party code will litter your compile units with macros. Microsoft is one of the biggest offenders with the Win32 macros wrapping codepage versus Unicode compiles, but even the various standards do this do you. For example, C99 defines some function-like macros – lowercase, taking one or more parameters.

There are several tricks you can employ to be resistant in your own code to macro tampering. And of course, the best practice is to only use macros where they have to be used, and keep macros restricted to all-upper-case names, and don’t use non-macros with all-upper-case names (and to try to use long macro names to avoid collision).

Disable function-like macro expansion

You can prevent the expansion of function-like macros by hiding the open-paren that must follow the macro name.

For example, let’s say you have a math package, and one element of your math package is a function that tests for NAN.

if (MyCompany::math::isnan(result))

Now, if you were to compile this in a file that also included C99 headers, you would get an interesting compile error, because C99 has a function-like macro named isnan(), and it might look like this

define isnan(x) \
     (sizeof (x) == sizeof (float) ? __isnanf (x) : __isnan (x))

In this case, if your code were written like this

if ((MyCompany::math::isnan)(result))

it would compile properly – the macro preprocessor would have the definition for the isnan macro, but it would not see an opening paren, so it wouldn’t expand the macro in this case.

Note that this only works for function-like macros; it will not work for object-like macros.

Push/pop macro definitions

Visual Studio introduced #pragma push_macro() and #pragma pop_macro() to push and pop macro definitions onto a stack. GCC, in order to stay compatible with Visual Studio, has also implemented this. Clang also supports push_macro and pop_macro.

Let’s say you very reasonably have a function in your code called CreateDirectory, put inside your own namespace (to protect it from other people using this common name), and that you are compiling in Windows.

#include <windows.h>
bool MyCompany::CreateDirectory(char const * dirPath, bool createSubDirs)

If you were to compile this, you would get a nasty compile error, because, inside um/fileapi.h, there is this macro

#ifdef UNICODE
#define CreateDirectory  CreateDirectoryW
#define CreateDirectory  CreateDirectoryA
#endif // !UNICODE

and so, at best you’d have your function actually called CreateDirectoryW, but if you keep operating system headers as limited in scope as possible, more likely you’d have some parts of your code with a CreateDirectory name, and others with a CreateDirectoryW name.

You could protect your code with push_macro and pop_macro

#include <windows.h>
#pragma push_macro("CreateDirectory")
#undef CreateDirectory
bool MyCompany::CreateDirectory(char const * dirPath, bool createSubDirs)
#pragma pop_macro("CreateDirectory")

and now (assuming you’ve protected all the instances in your code), you will compile as expected.

Microsoft added this for themselves, because their own code has this issue. In fact, if you look in atlmfc/include/afxinet.h, you’ll find this exact sequence to protect ATL code that uses CreateDirectory for a function name.


Boost is cool, and boost code is generally complex. The Asio library is cool, complex, and not really well documented.

Boost.Asio docs from Boost. The best part is really the tons of examples, but examples always suffer from, well, being examples. There is a separate document also written by Christopher Kohlhoff that is also useful to read.

The author of Asio keeps a blog:

StackOverflow thread Best documentation for Boost:asio points a few things out.

There is an online version of The Boost C++ Libraries by Schaling; chapter 7: Asynchronous Input and Output, is a decent read.

Oddly enough, while the Networking Library Proposal for TR2 was disparaged in the StackOverflow thread, it’s actually a pretty good thorough-yet-concise description of Boost.Asio. The down side is that it’s pretty old at this point (it was written in 2006). Maybe Boost.Asio has been really stable and hasn’t been changing a lot – I don’t know.

There is the book Boost.Asio C++ Network Programming by John Torjo, published February 22, 2013, also available as an ebook. However, this book has been somewhat disparaged as fluff or introductory.

Introduction to the Boost C++ Libraries, Volume II – Advanced libraries has several chapters on Boost.Asio.

Interesting article on making Boost as a Framework for MacOS/iOS.