From owner-freebsd-arch@freebsd.org Fri Oct 6 23:21:17 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22786E43EED for ; Fri, 6 Oct 2017 23:21:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0C836738E9 for ; Fri, 6 Oct 2017 23:21:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 087D7E43EEC; Fri, 6 Oct 2017 23:21:17 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07E91E43EEB; Fri, 6 Oct 2017 23:21:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE33E738E1; Fri, 6 Oct 2017 23:21:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 6E76B10A7DB; Fri, 6 Oct 2017 19:21:13 -0400 (EDT) From: John Baldwin To: Poul-Henning Kamp Cc: Baptiste Daroussin , "freebsd-arch@freebsd.org" , freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Date: Fri, 06 Oct 2017 16:21:05 -0700 Message-ID: <2706092.qpavixPdKK@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <29630.1507308468@critter.freebsd.dk> References: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 06 Oct 2017 19:21:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 23:21:17 -0000 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