Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-11-05 09:46:36

On 11/5/2012 4:16 AM, Olaf van der Spek wrote:
> On Sun, Nov 4, 2012 at 9:21 PM, Paul Mensonides <pmenso57_at_[hidden]> wrote:

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

For any extension that is just syntactic sugar or not desperately 
required (as hardware vectorization may be), yes.  Their existence is 
damaging in the long term.  Architecture-specific code is the minority. 
  Besides those comparatively rare cases, platform-specific code (and by 
"platform" I don't mean "compiler") should be the only C++ code that is 
non-portable.  Everything else should be portable almost by accident.  A 
particular author might be shortsighted and not care about portability, 
but portability in the general case is what has to happen for computer 
science (not just C++) to really move forward.  Platforms, compilers, 
and, in most cases, architectures need to be drop-in, interchangeable 
components, not foundations.

Even with hardware vectorization, I'm not sure how much it should be 
used at present other than in critical places.  The reason I say this is 
that I don't think we as academia/industry really know how to do 
multiprocessing (including vectorization) yet, and I suspect that it 
will end up being such that the overall way-of-coding, structuring data, 
etc. is significantly different--if not radically different.  As an 
aside, I actually think this one thing might be the one that kills off 
all current major (which implies imperative) languages--including C++.

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

In some ways, Windows deployment is easier because you can distribute 
in-directory DLLs for many libraries that don't require their own 
installation programs and largely avoid DLL hell.  In many ways, the 
Linux model is better because it has better facilities for reuse, but 
dealing with C++ ABI issues and version availablity issues can be a 
nightmare also.  Granted, you can do the same thing as with Windows with 
rpath if you really want to, but then you throw away memory and, usually 
less importantly, disk reuse (just as you get with Windows with 
in-directory DLLs).

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

Sorry, I didn't mean the tools themselves.  I'm referring to the single 
points of update and/or vetting of the content that those tools work 
with (at least, via official repositories).  They are fundamentally 
broken because all updates are essentially serialized through a single 
point.  That just doesn't scale despite herculian effort, and most Linux 
distros are way behind the most current releases of most software 
because of that.  Pressure for throughput at that point far outweights 
the available throughput--the outcome is inevitable.  Currently, 
deploying on Linux via any of the package management systems is a 
nightmare unless you only need old compilers and only rely on old 
versions of other libraries.  Besides the boilerplate distro differences 
in how one specifies a package, you run smack into version availability 
issues (related to which versions have so far gone through the single 
point) and ABI issues.

For the ABI-related stuff, the so versioning model could include an ABI 
stamp of some kind.  So, for example, I could build and install Boost 
1.52 with both --std=c++98 and --std=c++11 and have them coexist.  For 
handling the creation and processing of the (e.g.) dependency graph 
without single-sourcing it, I don't have any particularly great ideas.

Regards,
Paul Mensonides