From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 860F5BBBB for ; Fri, 17 Mar 2006 18:32:26 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k2HHWP7P023915 for ; Fri, 17 Mar 2006 18:32:26 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA26889 for ; Fri, 17 Mar 2006 18:32:25 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k2HHWNjY028402 for ; Fri, 17 Mar 2006 18:32:24 +0100 Received: from [192.168.1.200] (ppp11-225.lns1.syd7.internode.on.net [59.167.11.225]) by smtp3.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k2HHWGkL016966; Sat, 18 Mar 2006 04:02:17 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: RE: [Caml-list] Stroustrup et al. propose to introduce "lambdaclosures" in C++ From: skaller To: Alexander Bottema Cc: Caml List In-Reply-To: References: Content-Type: text/plain Organization: Async P/L Date: Sat, 18 Mar 2006 04:32:27 +1100 Message-Id: <1142616747.17736.56.camel@budgie.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 441AF2AA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 441AF2A7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; fergus:01 implements:01 garbage:01 gcc:01 stack:01 stack:01 pointer:01 garbage:01 high-level:01 boehm:01 semantics:01 generational:01 pointer:01 compaction:01 compaction:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Fri, 2006-03-17 at 09:12 -0500, Alexander Bottema wrote: > It is interesting to see that they are trying to implement closures in > C++, something I wanted for a long time. I proposed this YEARS ago (along with Fergus Henderson). No one seemed to know what they were for. Stroustrup neglected to mention this :) In any case, Felix implements this for C++ already, only does it properly -- unlike the weak proposal of N1968. > Unfortunately, I don't think it > is useful without having a proper garbage collector. It is. You should note gcc has provided anonymous functions for donkey's years for C. The caveat is obvious .. you can't use the function after the stack frame it is bound to has been popped off the stack. This is no different to not being allowed to return a pointer to a local variable. > If you read the > specification (5.2) you can see it is something they struggle with. I > think it is time that they added garbage collection to C++ as the > default memory allocation strategy like all other high-level languages. It isn't possible. And Boehm doesn't play so well with RAII. The way it is done with C++/CLI and Felix works, but is still difficult. In both cases new constructions are required, with distinct semantics. Felix is much smarter than C++/CLI since closures are standard, but the optimiser knows when it can reduce to ordinary C functions. My belief at the moment is that an advanced generational collector isn't appropriate for C++: it would yield WORSE results than a naive collector. For a start, C++ is heavily pointer based, so compaction is fraught with difficulties. Felix actually does provide compaction (and so far it proves slower to allocate in a linear arena than just calling malloc :) Secondly, C++ is multi-thread capable and no one would give that up for a collector. Thirdly, C++ is still imperative, and many people use the OO features quite heavily. Thus, write barriers would have a serious performance impact, not to mention code bloat. Fourthly, as Stroustrup pointed out C++ tends to spawn a small number of large objects, rather than a lot of small objects, and furthermore the RAII features mean manual deletion is often simple and better: not all structures are capable of supporting cycles. And finally, advanced collectors just don't work so well with pointers that move around. Stuff isn't boxed, and pointers run around inside objects. So reachability is very expensive to compute, compared to say Ocaml, where every pointer points at the head of a heap object. Even if C++ bans disguising pointers in ints, etc, it will be very hard to create an exact collector for a language that supports so many ways of aliasing, and conservative collectors just aren't the advanced generational kind you'd want in a functional language. So IMHO .. C++ is never going to have any kind of advanced collector: it just wouldn't work. It also seems pointless -- if you want GC and type inference and other nice stuff .. just use C# version 2. Just don't expect it to be fast :) -- John Skaller Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net