From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 08:57:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9C3106566B for ; Mon, 16 Feb 2009 08:57:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 148658FC13 for ; Mon, 16 Feb 2009 08:57:25 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA03708; Mon, 16 Feb 2009 10:57:14 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LYzHu-0005cD-5G; Mon, 16 Feb 2009 10:57:14 +0200 Message-ID: <49992A68.8010702@icyb.net.ua> Date: Mon, 16 Feb 2009 10:57:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: Andrew Reilly References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> <49986ABB.5040207@gmx.de> <20090216055602.GA70145@duncan.reilly.home> In-Reply-To: <20090216055602.GA70145@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Mallon , Marcel Moolenaar , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 08:57:27 -0000 on 16/02/2009 07:56 Andrew Reilly said the following: > The problem with C++ isn't really the functions that it > provides, it's the functions that it doesn't. Personally, I'd > like C++ a *lot* better if it required a garbage collecting > runtime. The problem with the way it works at the moment is > that object creation interacts with argument promotion and > constructors (and C++'s ability to grab references inside the > guts of objects, whch it inherited from C) in such a way that > you can have temporary object creation inserted by the compiler > in the middle of an expression, with no way to ensure that > the resulting object is reaped at the right time. And that's > because the compiler can't, in general, know what is the right > thing to do: if the called function retains the reference in a > long-lived structure then the temporary should be constructed > on the heap, and explicitly freed somewhere else. If it isn't > retained, then the temporary object should be collected as > the expression scope is exited. Since there's no way for the > compiler to make that call, you almost inevitably wind up with > either memory leaks or you constrain yourself to operate with a > restricted, not-quite-object-oriented style, which can't really > be enforced by the compiler. I don't need to mention what a bad > idea memory leaks are in kernel mode, right? This is the first time in my life that I hear about temporary objects on the heap and/or memory leaks through temporary objects. Either you are remembering a bug in some ancient C++ compiler or you are referring to some buggy code. As to the conversions through constructors, conversion operators and implicit type promotions - I personally had much less incidents because of that than I had incidents in C with passing/casting something incorrect via void*. This is to say that C++ is far from perfect and there are languages that are much better than it, but C is even (much) less perfect. And of all languages out there, I think, that C++ comes closest to a definition of "enriched", "better", "fortified" C. Which implies much lower entry barrier (and possibility for limited/gradual introduction). -- Andriy Gapon