English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: [Caml-list] Stroustrup et al. propose to introduce "lambdaclosures" in C++
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-03-17 (17:32)
From: skaller <skaller@u...>
Subject: RE: [Caml-list] Stroustrup et al. propose to introduce "lambdaclosures" in C++
On Fri, 2006-03-17 at 09:12 -0500, Alexander Bottema wrote:
> It is interesting to see that they are trying to implement closures in
> C++, something I wanted for a long time.

I proposed this YEARS ago (along with Fergus Henderson).
No one seemed to know what they were for. 
Stroustrup neglected to mention this :)

In any case, Felix implements this for C++ already,
only does it properly -- unlike the weak proposal of N1968.

>  Unfortunately, I don't think it
> is useful without having a proper garbage collector. 

It is. You should note gcc has provided anonymous functions
for donkey's years for C. The caveat is obvious .. you can't
use the function after the stack frame it is bound to has
been popped off the stack. 

This is no different to not being allowed to return a pointer
to a local variable.

> If you read the
> specification (5.2) you can see it is something they struggle with. I
> think it is time that they added garbage collection to C++ as the
> default memory allocation strategy like all other high-level languages.

It isn't possible. And Boehm doesn't play so well with RAII.

The way it is done with C++/CLI and Felix works, but is still
difficult. In both cases new constructions are required,
with distinct semantics.

Felix is much smarter than C++/CLI since closures are standard,
but the optimiser knows when it can reduce to ordinary C

My belief at the moment is that an advanced generational 
collector isn't appropriate for C++: it would yield WORSE
results than a naive collector.

For a start, C++ is heavily pointer based, so compaction
is fraught with difficulties. Felix actually does provide
compaction (and so far it proves slower to allocate
in a linear arena than just calling malloc :)

Secondly, C++ is multi-thread capable and no one would give
that up for a collector.

Thirdly, C++ is still imperative, and many people
use the OO features quite heavily. Thus, write barriers
would have a serious performance impact, not to mention
code bloat.

Fourthly, as Stroustrup pointed out C++ tends to spawn
a small number of large objects, rather than a lot of
small objects, and furthermore the RAII features mean
manual deletion is often simple and better: not all
structures are capable of supporting cycles. 

And finally, advanced collectors just don't work so
well with pointers that move around. Stuff isn't boxed,
and pointers run around inside objects. So reachability
is very expensive to compute, compared to say Ocaml,
where every pointer points at the head of a heap object.

Even if C++ bans disguising pointers in ints, etc,
it will be very hard to create an exact collector
for a language that supports so many ways of aliasing,
and conservative collectors just aren't the advanced
generational kind you'd want in a functional language.

So IMHO .. C++ is never going to have any kind of
advanced collector: it just wouldn't work.

It also seems pointless -- if you want GC and type
inference and other nice stuff .. just use C# version 2.
Just don't expect it to be fast :)

John Skaller <skaller at users dot sourceforge dot net>
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net