Subject: Re: [boost] [multimethods] Proposal: Open Multi-Methods
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2013-08-31 05:19:31
For lack of interest, I will not go forward with the submission
process. I would like to thank the people who expressed interest and
provided suggestions and encouragements.
To those who will find this thread in the future: it does not mean
that the project is dead - or if it is, I hope that it is because open
multi-methods have finally made it into C++. Normally you should be
able to grab the library from GitHub (https://github.com/jll63/yomm11)
and read the documentation from http://www.yorel.be/mm/ A series of
articles (ongoing at the time of this post) provides a detailed
discussion of the library on Code Project
On Sat, Jul 27, 2013 at 12:23 PM, Jean-Louis Leroy <jl_at_[hidden]> wrote:
> I am working on library that pretty much implements what Pirkelbauer,
> Solodkyy and Stroustrup describe in their paper "Open Multi-Methods for
> C++" - although there are some divergences. I have posted it on
> GitHub: https://github.com/jll63/multimethods. Please examine the
> files in the "examples" directory to get an idea of how to use it.
> Salient features are:
> * syntax: is relatively uncluttered. There are no limitations on the
> number of virtual arguments. Virtual and non-virtual arguments can
> be arbitrarily mixed. Multiple inheritance is supported, with some
> limitations - see below.
> * speed: close to a virtual function call when the hierarchies
> involved in the virtual arguments collaborate with the
> library. Calling a method that does nothing, with a single virtual
> argument in a single inheritance hierarchy is 33% slower than the
> equivalent virtual function call. The difference becomes unnoticeable
> if the functions perform a few simple maths operations. See
> * size: the dispatch table is constructed in terms of class
> groups. This results, most of the time, in a table devoid of
> redundancies. The size is bounded by the product of the number of
> specializers - not classes - in each dimension.
> * support for "foreign" class hierarchies: the library can be used
> without modifications to existing classes, at the cost of lower
> performance. Collaborating and foreign arguments can be freely
> mixed. Performance is still quite good, see the benchmarks.
> * next: a pointer to the next most specialized method is available
> inside method specializations - see examples/next.cpp.
> Alternatively, it is possible to call a specialization directly.
> Current limitations are:
> * restrictions on hierarchy: the classes involved in a method call
> must have a single root. Repeated inheritance is not
> supported. Multiple inheritance is supported, provided that the
> two conditions above are respected.
> * no overloading: multi-methods are implemented as constexpr function
> objects. This does not allow for overloading. This restriction can
> be easily side-stepped by wrapping multi-methods with different
> names in a set of overloaded functions. I know how to make
> multi-methods functions instead of objects, at the cost of a
> slightly less nice syntax for specializers. This is open to
> Besides, the library differs from Stroustrup et al's
> paper on the following points:
> * a specializer specializes only one multi-method: what would "next"
> mean otherwise? What would its static type be?
> * pure multi-methods are allowed: if called, an exception is
> thrown. This seems a better choice given that most of the time the
> declared virtual arguments will be abstract classes anyway.
> The library is essentially feature complete (if anything ever is). I am now
> going to
> work on the documentation, a build system, some clean up and compatibility
> (I tested it only with g++ 4.7.2 only so far).
> Is there interest in the Boost community for this stuff? If yes, I
> will adapt it to the guidelines and submit it for formal review. Of
> course, suggestions are welcome.
> Thank you for your time,
> Jean-Louis Leroy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk