Date: Sat, 7 Oct 2017 11:24:11 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, Baptiste Daroussin <bapt@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171007082411.GU95911@kib.kiev.ua> In-Reply-To: <2706092.qpavixPdKK@ralph.baldwin.cx> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> <2706092.qpavixPdKK@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171007082411.GU95911>