Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-11-05 07:16:25

On Sun, Nov 4, 2012 at 9:21 PM, Paul Mensonides <pmenso57_at_[hidden]> wrote:
>> 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

If gnu++11 is used, the goal of the authors isn't portable code, is it?
Basically you'd like to 'force' them to use c++11 by taking away the extensions?

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

I agree

> 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

For an app it's easy to depend on another lib. But for a lib,
depending on another lib that might not be easily available /
installable can be problematic.

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

They could be better but I don't think calling them fundamentally
broken is fair.

-- 
Olaf