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.3 required=5.0 tests=AWL 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 A5500BBC4 for ; Wed, 4 Mar 2009 23:45:14 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIHAIKTrknUnwcjZGdsb2JhbACCHZJOGgsDBwcPBsMmhAgG X-IronPort-AV: E=Sophos;i="4.38,303,1233529200"; d="scan'208";a="36107767" Received: from relay.ptn-ipout01.plus.net ([212.159.7.35]) by mail4-smtp-sop.national.inria.fr with ESMTP; 04 Mar 2009 23:45:14 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAACTrknUnw6U/2dsb2JhbACCHdY+hAgG Received: from fhw-relay07.plus.net ([212.159.14.148]) by relay.ptn-ipout01.plus.net with ESMTP; 04 Mar 2009 22:45:13 +0000 Received: from [87.112.234.120] (helo=leper.local) by fhw-relay07.plus.net with esmtp (Exim) id 1Lezpw-0003as-NW for caml-list@yquem.inria.fr; Wed, 04 Mar 2009 22:45:12 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? Date: Wed, 4 Mar 2009 22:50:36 +0000 User-Agent: KMail/1.9.9 References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <8763ipypx1.fsf@aryx.cs.uiuc.edu> <49AEF7EC.2000809@naughtydog.com> In-Reply-To: <49AEF7EC.2000809@naughtydog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903042250.36421.jon@ffconsultancy.com> X-Plusnet-Relay: 2c3c4f8b00702dd6d5b6f379948d0a8f X-Spam: no; 0.00; stl:01 high-level:01 high-level:01 low-level:01 allocations:01 fine-grained:01 fine-grained:01 threading:01 tpl:01 inlining:01 inlining:01 run-time:01 non-trivial:01 2009:98 fallen:98 On Wednesday 04 March 2009 21:51:40 Pal-Kristian Engstad wrote: > Yoann Padioleau wrote: > > Jon Harrop writes: > >> I'm very happy to see C++ dying. > > > > Is it ? > > C++ is definitely not dying. C++'s job market share has fallen 50% in 4 years here in the UK: http://www.itjobswatch.co.uk/jobs/uk/c++.do > Here are some reasons: > > * Most high-level languages decide the format of your data for you. > This is good for most things, but if a large part of your > application needs specific data layouts, then you are out of luck. That is not true for all high-level languages (e.g. .NET languages convey low-level data representations and XNA uses them directly) and it is a dominant concern for only a tiny number of applications. > * Most high-level languages can not support multiple forms of data > allocations. Some applications need a range of allocation > strategies, ranging from completely automatic (garbage collection) > to completely manual. C++ cannot provide efficient automatic GC. > * Most high-level environments do not allow for fine-grained control > of computing resources, e.g. soft real-time guarantees. Many high-level languages make it easier to satisfy soft real-time "guarantees", e.g. incremental collection vs destructor avalanches. > * Most high-level languages do not allow for C/C++ intrinsics, for > instance leveraging access to the SSE registers. That is easily resolved if it is not already present (which it is in Mono and LLVM already). > * Most high-level languages do not allow for fine-grained control, > for instance allowing different forms of threading mechanisms. F# offers the .NET thread pool, asynchronous workflows and wait-free work-stealing queues from the TPL. What more do you want? :-) > Of course, you can always say that you can use the foreign function > interface, but then you lose inlining and speed. The same is true of C/C++. You can get much better performance from assembler but calling assembler from C or C++ not only costs inlining and speed but even functionality because you have an ABI to conform to. > More importantly, you end up with a project with several different > languages. That is generally a very bad idea. A common language run-time is the right solution, not C/C++. > In short, most high-level languages will remain used for only for toys > and applications where speed and resource constraints is of no concern. You cannot feasibly parallelize or manage the resources of a non-trivial application in C/C++. The development cost of even attempting to do so is already prohibitively high and the result would be completely unmaintainable. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e