A better way is to define an implementation macro that takes the namespace as a parameter, and then force __COUNTER__ to be expanded once by the outer macro. (BOOST_PP_SUB has a pretty low upper maximum.)
Ah, good idea, thanks.
My opinion is that dlopen/dlclose should be exactly as safe for multimethods as they are for normal functions.
I prefer to call them "open methods", unless the context requires insisting on multiple dispatch. A study (see here https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice) shows that multiple dispatch is very rarely needed. I don't want potential users to think "multimethods, nice, but I don't have any need for that", and miss on the value of *open* methods with one virtual argument. But of course you are free to use the words you want ;-)
It might be better to assume that rebuilding the tables is rare. Then you can build a completely new table and swap it in atomically.
I expect it to be rare and I *know* that it is costly. I may be able to pull this off at the cost of some redundancy in the dispatch data. As of now, there is a global structure, shared by all methods, which contains just three words: a multiplier, a shift factor and a vector of "words" (either pointers or ints) that is a mixed bag of things (a collision free hash table, the equivalent of a vtable for each class, dispatch tables and strides for *multi* methods, slots occupied by each method). Those three words can be folded together and accessed via a pointer (to be atomically swapped). Each method contains a pointer inside that global vector, to the first slot (followed by the second slot, a stride, a slot, etc for multi-methods). That's the problem: one pointer per method. But I think I can rearrange the dispatcher to work with just the pointer from the method. I will have to replicate the content of that global structure for each method, before the first slot. Then a method could be swapped atomically. All the methods would *not* flip to the new table atomically, but I think that this may still give the correct behavior...