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,HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 9F0ABBBC4 for ; Wed, 4 Mar 2009 22:53:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuABAEeHrkmgISwrmWdsb2JhbACCIDGSMgEBAQEBCAsKBxGzQAmPeYJXgTEG X-IronPort-AV: E=Sophos;i="4.38,303,1233529200"; d="scan'208,217";a="25078390" Received: from unknown (HELO ironport02a.scea.com) ([160.33.44.43]) by mail1-smtp-roc.national.inria.fr with ESMTP; 04 Mar 2009 22:53:56 +0100 X-IronPort-AV: E=Sophos;i="4.38,303,1233561600"; d="scan'208,217";a="5067612" Received: from inbetweener01.scea.com ([160.33.45.195]) by ironport02a.scea.com with ESMTP; 04 Mar 2009 13:53:53 -0800 Received: from postal1-dog.naughtydog.com (intmail.naughtydog.com [10.15.0.14]) by inbetweener01.scea.com (Postfix) with ESMTP id CCB65F0508; Wed, 4 Mar 2009 13:53:53 -0800 (PST) Received: from [127.0.0.1] ([150.0.6.116]) by postal1-dog.naughtydog.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 13:52:38 -0800 Message-ID: <49AEF7EC.2000809@naughtydog.com> Date: Wed, 04 Mar 2009 13:51:40 -0800 From: Pal-Kristian Engstad User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Yoann Padioleau , "caml-list@yquem.inria.fr" Subject: Re: [Caml-list] stl? References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <87eixdz12l.fsf@aryx.cs.uiuc.edu> <200903042007.43232.jon@ffconsultancy.com> <8763ipypx1.fsf@aryx.cs.uiuc.edu> In-Reply-To: <8763ipypx1.fsf@aryx.cs.uiuc.edu> Content-Type: multipart/alternative; boundary="------------090704090409060902070401" X-OriginalArrivalTime: 04 Mar 2009 21:52:38.0290 (UTC) FILETIME=[88DD1720:01C99D13] X-Spam: no; 0.00; stl:01 high-level:01 high-level:01 allocations:01 fine-grained:01 fine-grained:01 threading:01 inlining:01 pke:01 emacs:01 allocations:01 threading:01 inlining:01 pke:01 emacs:01 This is a multi-part message in MIME format. --------------090704090409060902070401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Yoann Padioleau wrote: > Jon Harrop writes: > >> I'm very happy to see C++ dying. >> > > Is it ? > C++ is definitely not dying. 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. * 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. * Most high-level environments do not allow for fine-grained control of computing resources, e.g. soft real-time guarantees. * Most high-level languages do not allow for C/C++ intrinsics, for instance leveraging access to the SSE registers. * Most high-level languages do not allow for fine-grained control, for instance allowing different forms of threading mechanisms. Of course, you can always say that you can use the foreign function interface, but then you lose inlining and speed. More importantly, you end up with a project with several different languages. That is generally a very bad idea. In short, most high-level languages will remain used for only for toys and applications where speed and resource constraints is of no concern. Which is sad, because C++ has many, many problems - the most major one being that it is so easy to produce bugs. Thanks, PKE. -- Pål-Kristian Engstad (engstad@naughtydog.com), Lead Graphics & Engine Programmer, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North, Santa Monica, CA 90404, USA. Ph.: (310) 633-9112. "Emacs would be a far better OS if it was shipped with a halfway-decent text editor." -- Slashdot, Dec 13. 2005. --------------090704090409060902070401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yoann Padioleau wrote: 
Jon Harrop <jon@ffconsultancy.com> writes:
  
I'm very happy to see C++ dying.
    

Is it ?
C++ is definitely not dying.

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.
  • 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.
  • Most high-level environments do not allow for fine-grained control of computing resources, e.g. soft real-time guarantees.
  • Most high-level languages do not allow for C/C++ intrinsics, for instance leveraging access to the SSE registers.
  • Most high-level languages do not allow for fine-grained control, for instance allowing different forms of threading mechanisms.
Of course, you can always say that you can use the foreign function interface, but then you lose inlining and speed. More importantly, you end up with a project with several different languages. That is generally a very bad idea.

In short, most high-level languages will remain used for only for toys and applications where speed and resource constraints is of no concern. Which is sad, because C++ has many, many problems - the most major one being that it is so easy to produce bugs.

Thanks,

PKE.
-- 
Pål-Kristian Engstad (engstad@naughtydog.com), 
Lead Graphics & Engine Programmer,
Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Emacs would be a far better OS if it was shipped with 
 a halfway-decent text editor." -- Slashdot, Dec 13. 2005.
--------------090704090409060902070401--