From owner-freebsd-arch@freebsd.org Fri Oct 6 18:41:02 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 47B4BE3E5B4 for ; Fri, 6 Oct 2017 18:41:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 23E366A5AE for ; Fri, 6 Oct 2017 18:41:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 20378E3E5AD; Fri, 6 Oct 2017 18:41:02 +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 1FB3CE3E5AB; Fri, 6 Oct 2017 18:41:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A771C6A5AC; Fri, 6 Oct 2017 18:41:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id k66so7365823wmd.4; Fri, 06 Oct 2017 11:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JviZBxwCn7c+LM4bsaPOhWyKV3CEnnnIm+hBBbe4n8Y=; b=sG05YUF03okNbngTwG3+qc/3MomJTf7IPladVCv4dHN8JiiC2zF7ZxHs2tOrwHlp5f KrgBSuX+OEvhjdjrOIfNMHK3JFm1NuoUAAfydaND8TEwjOL8UXAQlkAZyASWkPqH0hou pvc/sssEx2K5DBA7PfL18WFDS5vOo105ryGxh3Z1grK0rCEVC86RNijKHtGts8Qr+QkS nYJ30Eydn94Nn15R+D/dMenGtFUdO+BG0QInCihd3v/MllRHTvEEry8Fo4a1CUy56GSl zA77+v0jQG7CcZ9Td5bQ0po9T+8gbMvaed+ksklk3mM/V5vKEZCHUHWMU3W+R2OL5Uem 4xeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JviZBxwCn7c+LM4bsaPOhWyKV3CEnnnIm+hBBbe4n8Y=; b=kykTArcs5e2uN3o9b9WqfAhPuR2Bvc+sQg6zJ5u+PWYUFgvx7F9p1SB/GnU6f311xV fxEXzpq4IVIqlCUlAU6sISW9ySfzwvul975kIA5vxNhzC8fFtm/TcsT4iI3QTYMJxk5E UMELNkPDuXjZxBQu+e4JnByY4SOsu2Q+AbDtLVwCNIQTTqPlDoW+c3heXYoT7lKZ2/v7 rAquTL7ux19K0dKrUR1s2bJKplgjTF3IWEX6NFlnEhbr/icvIyxYllB2AG6YgAb4UlIY rAc8l3Ygjm1rBNW5qMzKDXlSRIjLkrSFJfUPryJX+MWHToPzbMfNc/LPyr+bvIrwkPe2 Pgaw== X-Gm-Message-State: AMCzsaUXQ/XAYj9QrWeX/rd/BL+zA1m/GC04rlh+wrCFf6psON7x2YGm v6zsPi/94TpkssnKxC6kBszGEU+TbxEZc7eR97gzeQ== X-Google-Smtp-Source: AOwi7QCUyuSw8hB1D4ncCyT07fn/LicsgTAHbCgkeiBZiX59nLP8pcov1rfo5aV2iBIu5+Kc8E7Tgl7W7bBAlgyZuCY= X-Received: by 10.223.145.105 with SMTP id j96mr2758275wrj.273.1507315260173; Fri, 06 Oct 2017 11:41:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.86.70 with HTTP; Fri, 6 Oct 2017 11:40:59 -0700 (PDT) In-Reply-To: <29630.1507308468@critter.freebsd.dk> References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> From: Adrian Chadd Date: Fri, 6 Oct 2017 11:40:59 -0700 Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: Poul-Henning Kamp Cc: Baptiste Daroussin , "freebsd-arch@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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 18:41:02 -0000 On 6 October 2017 at 09:47, 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. I don't mind it as long as it's "no C++ runtime bloat please". But yes, I also feel the pain of where you start that path and then suddenly you find you're al in that path. (I face this at work right now on linux platforms because a "little C++" becomes .. not little.) -adrian