Boost logo

Boost :

Subject: Re: [boost] C++ announcements coming tomorrow
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-11-04 15:21:05

On 11/4/2012 5:57 AM, Olaf van der Spek wrote:
> On Sun, Nov 4, 2012 at 2:43 AM, Paul Mensonides <pmenso57_at_[hidden]> wrote:
>>> I disagree with the view that it's categorically wrong for compiler
>>> vendors to implement extensions, as long as there is a way to turn them
>>> off, and as long as the standard library works in a std-compliant way
>>> when they're off.
>> To be clear, I understand the need for compiler-specific things like pragmas
>> (and maybe even things like __stdcall and __cdecl). I do have a problem
>> with feature extensions of any kind, however. The reason is not because I
>> believe the language to be sacrosanct so much as that it breeds lack of
>> portability.
> Does it? If the goal is portable code, you compile the code on
> multiple platforms and compilers, and unintended use of extensions is
> easily detected.
> Lack of full support for standard C++ or C++11 and bugs are a much
> bigger problem IMO as they sometimes require non-trivial workarounds
> that complicate the code.

Yes, it does. Taking aim at GCC instead, a huge amount of GNU code will
not compile without --std=gnu++11 instead of --std=c++11. Even more of
it won't compile without a POSIX environment--even ignoring the build
system and autotools. The point is that, in many cases, portability
should be accidental. I.e. with relatively few platform-specific
exceptions (which should be isolated and generalized) programming is
done against the abstract machine specified by the C++ standard. That's
the compiler user's part of the contract. The compiler developer's part
of the contract is to implement a compiler that compiles the language
specified by the C++ standard.

Sure, lack of full support for the language and the presence of bugs are
a huge problems. However, towards the end of 2012, I'm not particularly
irrated by the current state of C++11 conformance. I am irrated by set
in stone "won't fix" responses to bug reports and broken,
mis-implemented features.

>> If compilers implemented 100% of the language (allowance being made of
>> course for features recently added to the language) and did not provide
>> extensions (which by their very existence encourage their use), then
>> libraries can be developed to generalize platform-specific details (not
>> compiler-specific details) (e.g. Boost.Filesystem, Asio, etc.) and a
>> hierarchy of portable libraries *can* be developed.
> Some libs should be part of the standard to lower the barrier to start
> using them.

Of course. However, I consider that to be a means to guarantee that the
presence of those libraries included in the "price" of the compiler and
support of that compiler. There is no way that every useful library in
every useful domain can be added to the standard library. For C++
software development to really flourish, libraries from outside the
standard need to be portable and reusable.

Take file system and networking libraries, for example. I can use those
libraries regardless of whether the standard contains equivalent
libraries because Boost contains them. I think adding networking
support and file system support to the standard library is a good thing,
but I can do those things now and fairly easily because Boost developers
tend to bend over backward to make things as portable as possible. But
it should not be so difficult to write portable code. We should not
need to have a Boost codebase that is saturated with workarounds. Whose
fault is that? The presence of those workarounds is a symptom, but what
is the root cause? Compilers. And Boost is just one collection of

Yes, some libraries like Filesystem and Asio have to contain
platform-specific code (i.e. alternate implementations for different
platforms), but they encapsulate and generalize the platform
differences. In some ways, that is their most important function.

> Building/using a (C++) library on Windows is also far less than ideal,
> which IMO is a big problem for C++ on that platform.

Well, we all know Windows is fundamentally broken and getting worse. If
you use VC++ on Windows, yes. I use one of the MinGW ports of GCC on
Windows or a cross-compiler, and other than over-reliance on
--std=gnu++XX and piss poor support for some of libstdc++ where its
implementation is heavily dependent on POSIX (e.g. threading), it
appears to work well. I use Boost a lot and don't have trouble building
it except altering the jam file every time to replace mingw with gcc. I
also use Qt for UI-related stuff, and building that is not terribly
difficult either. It gets more difficult with other libraries because
when libraries "support" Windows, that tends to imply VC++--which is a
problem. We need to get to a point where one doesn't target
*compilers*. Instead one targets C++ and some platform. From there, we
can generalize the platform-specific parts with libraries such that
everything else can target C++.

OTOH, Linux has its issues also such as its massive assumption of a
system-wide particular version of GCC with no C++ ABI encoding in the
shared object versioning. The Linux package management models (i.e.
apt-get, rpm, emerge) are also fundamentally broken because they don't
scale (many-to-one-to-many vs many-to-many).

Paul Mensonides

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