Boost logo

Boost :

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-07-22 12:25:00

> This is a case where Boost's policy of appending all of the
> toolset/configuration/threading model etc. to the library name is
> somewhat unique and, and generally incompatible with how the rest of
> the world works. In general, I've found it a hindrance to
> interoperability, and solving a problem which I didn't have in the
> first place. No one else does it, and there's likely a good reason
> for that! At most, I add a 'd' debug postfix on Windows, and that's
> it (this is handled by CMake as a standard behaviour). If I need
> multiple configurations, I build them separately and explicitly; I
> don't expect it of the build system itself.

I had a feeling this would come up, and as the instigator of this let me
explain how/why it happened.

A very long time ago, before Boost as it happens, I had a toy C++ regex
library, I released it to the world and it got some exposure and
feedback. However, I was getting about 1 support request a week from
folks who were linking regex built one way to an application built in
some binary incompatible way (this is with Visual Studio). Now that's a
lot of support requests for a library that had only limited exposure
pre-boost, pre-github, and yes, pre-sourceforge too. I dread to think
how many support requests it would generate now, had this issue not been
solved via name mangling and auto-linking when using Visual Studio. It
means it "just works" on a platform that has a multitude of different
compiler runtimes, all binary-incompatible with each other. Sorry, but
a simple "d" suffix on Windows doesn't even begin to cover the whole
heap of pain that results from doing this wrong.

Aside 1: If I were forced kicking and screaming to abandon the name
mangling, then mangling the library namespace would mitigate this
somewhat, but not enough IMO.
Aside 2: If the VS CMake generated files were good enough, then the
canonical way of using Boost under Visual Studio would be to reference
our project files from your applications solution. Then the libraries
your using would always be built with the same options that you're using
in your project.... well nearly, this actually requires quite a bit of
manual intervention to set the properties of every dependent library the
same, plus a fair proportion of VS developers seem not to know how to
reference an external library from their IDE anyway :(

In short, I simply can't express how much easier name mangling makes the
developers life.

I can of course see that on other platforms, this makes no sense at all,
and assuming there is "one true version" makes perfect sense.

Best, John.

This email has been checked for viruses by AVG.

Boost list run by bdawes at, gregod at, cpdaniel at, john at