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=1.2 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 53961BBC4 for ; Wed, 4 Mar 2009 15:26:38 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAAserklDWxLCaWdsb2JhbACBTpMzFAQiBLJZhzaITIQIBg X-IronPort-AV: E=Sophos;i="4.38,301,1233529200"; d="scan'208";a="22037898" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail2-smtp-roc.national.inria.fr with ESMTP; 04 Mar 2009 15:26:37 +0100 Received: from kuba-laptop.bertec.net (kuba-laptop.bertec.net [192.168.2.48]) by server1.bertec.net (Postfix) with ESMTP id 9EA1810575C for ; Wed, 4 Mar 2009 09:26:36 -0500 (EST) Message-Id: From: Kuba Ober To: caml-list@yquem.inria.fr In-Reply-To: <200903032336.53089.jon@ffconsultancy.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Caml-list] stl? Date: Wed, 4 Mar 2009 09:26:36 -0500 References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <87zlg2z19g.fsf@aryx.cs.uiuc.edu> <200903032336.53089.jon@ffconsultancy.com> X-Mailer: Apple Mail (2.930.3) X-Spam: no; 0.00; stl:01 unboxed:01 pointers:01 stl:01 subset:01 stepanov:01 ocaml's:01 allocator:01 cheers:01 caml-list:01 data:02 slower:02 objects:02 constructs:02 alex:03 >> I've worked a little bit with C++ using unboxed objects, that >> is without introducing pointers (similar to boxing) in templates, >> like list
instead of list, and passing them >> as value in parameters, or returning them, >> and it was far less efficient because there was lots of copy, >> and you could not use then virtual method on them. So in the >> end the C++ programmer I thing manually re-introduce boxing >> when using STL if he wants good performance, and he can not really >> rely either on the default copy/equal implementation provided >> by those templates. So, yes STL makes it possible to do things, >> but programmers don't want them, or only in very few cases where >> one need extreme performance. > > The STL is extremely slow. If you want fast code in C++ then you > drop to the C > subset. Alex Stepanov tried and failed to implement efficient > constructs in > the STL. Furthermore, the memory consumption of his library is > awful. OCaml's > GC is far more efficient with memory whilst permitting easy sharing. I don't think that STL is generally slow. There are corner cases where you'd do well to use a custom allocator or somesuch, but in methinks contemporary STL implementations have performance on par with C. If you code using STL in a way which copies data all around, it will be no slower than doing all the copying in C. Otherwise known as comparing apples to apples. Cheers, Kuba