Re: [Caml-list] stl?

[Jon Harrop <jon@ffconsultancy.com>]

On Wednesday 04 March 2009 21:51:40 Pal-Kristian Engstad wrote:
> Yoann Padioleau wrote:
> > Jon Harrop <jon@ffconsultancy.com> 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