Re: [boost] C++ announcements coming tomorrow

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 
libraries.

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).

Regards,
Paul Mensonides