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