Hi,

Are virtual base classes supported?

Yes, at a cost in performance, as usual when virtual bases are involved. If the class in the specializer virtually derives from the class declared in the same position in the multi-method, dynamic_cast<> will be used to adjust "this". Otherwise static_cast will be used. There will be a small additional cost for accessing the pointer to the method table - or any virtually inherited data FTM.

Maybe “virtual_” should be renamed to “virtualize” or “virtualized,” to avoid having a trailing underscore in a non-member name.

I'm trying to be as close as possible to the syntax used by Stroustrup's proposal - which I like a lot. Virtual is the familiar keyword in C++ to denote dynamic binding. Other possibilities would be late<> or dynamic<>. A trailing underscore is but one of the decorations some people put on data members, AFAIK the practice hasn't reached consensus.

A good way to document is to write a Doxygen comment as you write your class, function, or macro prototype.

I have used Doxygen in the past and I was happy with it. Not too sure it's the best way to document macros and templates, and one base class that contains only one pointer for internal use.

But looking at your “next.cpp” example, you should start with documenting the “selector,” “virtual_,” “MM_CLASS,” “MM_INIT,” “MULTIMETHOD,” “BEGIN_METHOD,” “END_METHOD,” and “initialize” items.

That is pretty much all there is to document indeed. Plus MM_FOREIGN_CLASS (for non-intrusive multi-methods), two templates and one concept (to use without the macros). I am very tempted to change BEGIN_METHOD into BEGIN_SPECIALIZER.

Anything in your implementation classes that don’t have to be seen by public code can be make private.

I am not convinced of the merit of encapsulating *internal* classes - then probably providing getters and setters for all the members. This is a small set of classes that collaborate together in secret like friends. Don't get me wrong, I am not arguing against encapsulation in general.

Non-public types can go in a detail namespace.

Exactly! "namespace detail" means "private", don't touch it, you don't even know it's there ;) By the way, I'll move come classes (the slot allocator and the method resolver) to the cpp file. Jean-Louis