Subject: Re: [boost] [multimethods] Proposal: Open Multi-Methods
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2013-07-31 14:45:57
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk