From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id EA61BBBAF for ; Sat, 11 Apr 2009 16:21:28 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloBALND4EnUnwcjjmdsb2JhbACCIJQVAQEBAQkLCAkPBrJ3g3wG X-IronPort-AV: E=Sophos;i="4.40,171,1238968800"; d="scan'208";a="38312906" Received: from relay.ptn-ipout01.plus.net ([212.159.7.35]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Apr 2009 16:21:28 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEFAN9E4EnUnw6T/2dsb2JhbACCIcdTg3wG Received: from ptb-relay03.plus.net ([212.159.14.147]) by relay.ptn-ipout01.plus.net with ESMTP; 11 Apr 2009 15:21:25 +0100 Received: from [87.113.30.188] (helo=leper.local) by ptb-relay03.plus.net with esmtp (Exim) id 1Lse5E-0000aj-Rq for caml-list@yquem.inria.fr; Sat, 11 Apr 2009 15:21:24 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCaml and Boehm Date: Sat, 11 Apr 2009 15:27:58 +0100 User-Agent: KMail/1.9.9 References: <4a708d20904101313s49ef3b75m45202b6bda800b77@mail.gmail.com> <49E09C2D.4080906@starynkevitch.net> <4a708d20904110711i199ef805h611a04d823c8fb51@mail.gmail.com> In-Reply-To: <4a708d20904110711i199ef805h611a04d823c8fb51@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904111527.58652.jon@ffconsultancy.com> X-Plusnet-Relay: db4c3e947012b3b272357341f3a3c9bb X-Spam: no; 0.00; ocaml:01 boehm:01 lukasz:01 pointers:01 pointers:01 incorrectly:01 2009:98 frog:98 garbage:01 wrote:01 heap:01 caml-list:01 off-topic:02 slower:02 deallocate:03 On Saturday 11 April 2009 15:11:38 Lukasz Stafiniak wrote: > (Another question which is off-topic for this list is whether smart > pointers in their situation would be a high performance hit.) Depends what "their situation" is. :-) Smart pointers are adequate for specific domains where performance is unimportant and cycles cannot occur, like handling the destruction of GUI elements. In general, smart pointers are orders of magnitude slower than garbage collection because they bump values in the heap every time they change hands. Also, don't forget that many people incorrectly claim that smart pointers deallocate at the earliest possible point when, in fact, they typically keep values alive longer than necessary. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e