Open Multi-Methods for C++

Peter Pirkelbauer, Yuriy Solodkyy, and Bjarne Stroustrup. Open Multi-Methods for C++. Proc. ACM 6th International Conference on Generative Programming and Component Engineering (GPCE). October 2007.

Multiple dispatch – the selection of a function to be invoked based on the dynamic type of two or more arguments – is a solution to several classical problems in object-oriented programming. Open multi-methods generalize multiple dispatch towards open-class extensions, which improve separation of concerns and provisions for retroactive design. We present the rationale, design, implementation, and performance of a language feature, called open multi-methods, for C++ . Our open multi-methods support both repeated and virtual inheritance... ...our approach is simpler to use, catches more user mistakes, and resolves more ambiguities through link-time analysis, runs significantly faster, and requires less memory. In particular, the runtime cost of calling an open multimethod is constant and less than the cost of a double dispatch (two virtual function calls). Finally, we provide a sketch of a design for open multi-methods in the presence of dynamic loading and linking of libraries.

Who said C++ isn't evolving?

The discussion in section 4 of the actual implementation (using EDG) is particularly detailed, which is a bonus.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Evolving???

Who said C++ isn't evolving?

I'll say it's evolving when it has garbage collection...

Garbage collection can

Garbage collection can easily be added on with a library. It's years since I've programmed in C++ without garbage collection and it's sooo nice to not have to worry about contorting yourself to write destructors and make sure that temporaries are destroyed at the right time.

In fact, as long as C++ stays agnostic about threads and DLLs it pretty much *has* to leave GC to a library that understands the platform and that the user can modify and tune.

Generic functions can't reasonably be added without compiler support.

Not really.

Garbage collection can easily be added on with a library.

There are big problems with gc being a library:

1) problem of initialization: who initializes what? should initialization be from 'main'? from the dll? from the first one to use the gc malloc function? etc.

2) problem of performance: conservative collectors scan big areas of memory that need not be scanned. A great deal of work is needed by the programmer to optimize the code, and it is not possible in some cases. A copying collector can't be implemented.

3) problem of overloading new and delete: if you don't have the source code, you must overload new and delete globally. But if the libraries you use do that as well, you are doomed.

4) problem of finalization: as it is right now, Boehm's gc does not call finalizers at the end of the program, because the gc might not be the last thing the process does.

It's years since I've programmed in C++ without garbage collection

Everybody says that :-). I must be the only one that can't use Boehm's gc (do other gcs exist? nope). I've recently tried to use the Boehm's gc, but I have severe problems, still unsolved. See this discussion for details.

C++ GC

Have you looked at the Ravenbrook Memory Pool System at all? You might find it interesting.

Alternatively, you might find programming in Felix worthwhile.

Is any of this related to

Is any of this related to the paper for discussion?

Thanks...but:

The RMPS seems incomplete...at least the documentation is. And without documentation, I can't suggest it to my company.

Felix looks more promising, but the language is not the problem.

OK I bit..

..but there was no worm on the hook. Is there something here beyond something like talloc? This is useless:

"1. Introduction

This is the reference manual for the Memory Pool System.

This document is quite incomplete. At present it consists simply of reference descriptions of a number of MPS symbols (section 3). Many MPS symbols are not described here (see section 4 for a list). There are also no overview or protocol-oriented sections.

2. Overview
*empty*
3. Reference
..."

I especially like this one:
"This function does not perform any particular operation. "

LOL!

Back to the future

Seems like there are lots of good ideas which eventually, hopefully, people are driven back towards - be it garbage collection, generics, closures, extension methods, multiple dispatch, functional style, immutability/value vs. object semantics, avoiding shared mutable state, etc. I think what is missing for the masses is a concise explanation of when to use them, a la Design Patterns perhaps. So people have to beat their heads against a square Visitor Pattern in a round universal method hole before they see the light?

(I wonder if a big html table of "feature/style" to "benefit" would help people? E.g. "functional" to "new method", "oop" to "new data type", that kind of thing. Those who don't know but want to learn could read up starting from that hopefully concise and therefore hopefully more accessible starting point.)

I guess the conclusion I see is that a good language either says "we stop here for ever" like C (vs. all the proposed Java extensions which bend things beyond the breaking point, and makes me wonder if/how C++ manages not to fall apart under similar evolutionary demands), or it is designed to say "we're easy to update with old-new ideas" via some kind of easy libraries (I guess the Actors stuff in Scala might be sold as that kind of power?).

I just got my copy of CTM for Xmas so I really have to learn Oz :-)

How does this compair to . . .

I have not read this through yet, but at a glance it looks a lot like Cmm (http://www.op59.net/cmm/cmm-0.27/users.html) and Frost (http://src.wongr.net/frost/) only more limited than either.

Section 6 deals with related

Section 6 deals with related work including Cmm (6.1).

Multi-methods are not being integrated

Multi-methods are currently not being integrated in the next C++ standard. This paper is only a reference for people wanting to propose evolutions on the subject.

This doesn't mean, however, that C++ isn't evolving. One just needs to consult the papers submitted in its open standardization process to realize that.
Even without it evolving, though, I believe the functional languages community still has a lot to learn from C++, since a lot of its features are very novel and not known well enough in this community.

And about memory management, C++ perfectly allows usage of any technique, including moving garbage collectors, by defining custom pointer types, allocators and strategies; even though people prefer deterministic solutions to memory management, especially ones without sharing of state between scopes.

Even without it evolving,

Even without it evolving, though, I believe the functional languages community still has a lot to learn from C++, since a lot of its features are very novel and not known well enough in this community.

Just out of curiosity, could you name a few? I don't know C++ very well, at all.

EDIT: the quote tag didn't seem to do much .. changed it to a cite tag :/

Color me curious, too...

...since I've programmed in C++ for over a decade and a half and am struggling with the comment as well.