Version française
Home     About     Download     Resources     Contact us    
Browse thread
stl?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Pal-Kristian Engstad <pal_engstad@n...>
Subject: Re: [Caml-list] stl?
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.