Making C++11 a hard requirement for FreeBSD

[Konstantin Belousov]

On Fri, Oct 06, 2017 at 04:21:05PM -0700, John Baldwin wrote:
> On Friday, October 06, 2017 04:47:48 PM Poul-Henning Kamp wrote:
> > If we allow C++ in libc, it should not merely be for the convenience
> > of a few programmers, but because we have a vision for how it that
> > makes the world, or at least FreeBSD, a better place.
> > 
> > Having C++ in libc is no trivial detail, there is a number of areas
> > where this causes bootstrapping issues and conflicts.
> > 
> > We can solve those issues with unsightly local hacks, most
> > notably a bogo-malloc to malloc while C++ constructs jemalloc.
> > 
> > But hand on heart, we all know that is a bad idea, all of us have
> > been down that road before, and we also know that there is no way
> > to be a little bit pregnant.
> > 
> > The other way, the right way, to accomodate the jemalloc request
> > is to go all in.
> > 
> > Nothing in the ISO verbiage says that you cannot have C and C++
> > runtimes in the same library, as long as your linker knows the zip
> > code of it.
> > 
> > Libc as a combined C and C++ runtime can be implemented a lot cleaner
> > than a libc which hides C++ components in the closet.
> > 
> > So that is my input to this question:
> > 
> > Either we tell the jemalloc people "sorry, it's called libc for a
> > reason" or we decide to make our libc a native C *and* C++ runtime.
> > 
> > I see no sane or even possible "middle ground" or compromise position.
> 
> Hmm, I don't quite agree.  I think it's possible to use a restricted C++
> (no rtti, no exceptions, no STL) such that you are only using language
> features like templates or 'auto' without requiring runtime support.  I
> think that is the requirement we would place on the jemalloc implementation
> for it to remain in libc.
This is a requirement not only on jemalloc, but also on the compilers.
I am much more worried about C++ compiler's runtime requirements than
the ability of the jemalloc developers to restrict used language features
to the subset which does not need some external support _at the current
compiler version_.

Seeing the route that clang took making C compiler unusable for normal
work, I am just sure that clang++ would cause a lot of troubles if we
ever try to rely on the undocumented and unpromised detail of the
current implementation.

> Right now the C++ runtime is split into a
> couple of different pieces: libc++ (STL bits, roughly), libcxxrt (rtti
> / exception support), libgcc_s (either llvm libunwind or gcc for _Unwind_*
> along with intrinsics from compiler-rt).  All of these are variable in
> some sense (if you wanted to build a GCC-based system you might want to
> use libstdc++ instead of libc++, libgcc_s already varies by platform,
> and upstream in LLVM there is already a libcxxabi alternative to libcxxrt
> plus the GNU libsupc++).
> 
> I think bundling any of those pieces into libc makes our system less
> flexible and different from all the other UNIXy systems currently in
> vogue.
This also hits the ABI stability hard, see my other reply.