[LLVMdev] Closed virtual dispatch (was: Introduce a section to the programmers manual about type hierarchies, polymorphism, and virtual dispatch.)

[Bruce Hoult]

It might be useful to look at how Apple's 'Dylan' language does this. It's
all been defined and implemented and in use by the (admittedly small)
community for 15 - 20 years.  CMU's 'd2c' compiler, in particular, uses
these to produce code with speed almost indistinguishable from C.


A 'sealed' class is precisely one that can not have subclasses defined
outside of its library (compilation unit)

http://opendylan.org/books/drm/Declaring_Characteristics_of_Classes

Define Sealed Domain may also be of interest:

http://opendylan.org/books/drm/Define_Sealed_Domain


On Wed, Jan 28, 2015 at 10:05 PM, David Chisnall <
David.Chisnall at cl.cam.ac.uk> wrote:

> On 27 Jan 2015, at 17:13, Philip Reames <listmail at philipreames.com> wrote:
> >
> > Given we have a large number of compiler authors and contributors to the
> C++ language spec, it seems really odd to me that we can't solve this
> problem in a more elegant way. The tagged-dispatch as a sealed world
> replacement for virtual dispatch is one that comes up on a pretty regular
> basis.  Might it be time to figure out how to generalize this and propose
> either a clang extension or a language mechanism for some future version of
> C++?
>
> One of the motivations for being able to mark a class as final in Java was
> to allow compilers to perform optimisations on the assumption that there
> would never be any subclasses (I don't believe any modern JVMs take
> advantage of this as it's mostly only useful to AoT compilers, but maybe
> ART does).  For this idiom, the guarantee that you want is something
> slightly broader than final, it's that, at some known point, all subclasses
> will be visible to the optimiser.  This is a bit difficult to do in the
> files-are-approximately-compilation-units model, but a bit easier with LTO
> (though re-inferring enough information to do devirtualisation at this
> level is a bit tricky).
>
> C++, at the language level, unfortunately has no notion of a shared
> library.  This is very problematic in some places in C++11 (the semantics
> for when constructors and destructors are run for thread_local objects in
> the presence of multiple threads and library loading and unloading are very
> poorly defined) and also makes it difficult to have a package-final or
> similar to indicate that no subclasses outside of this library are
> permitted.
>
> Or, if the goal is to put a little bit more burden on the programmer but
> give greater flexibility in implementations, I believe that one of the
> people in this thread is the head of the reflection subcommittee in WG21,
> so may already be reviewing proposals that would make it easier to
> implement generically...
>
> David
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150128/22adb1cf/attachment.html>