Boost logo

Boost :

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, gregod at, cpdaniel at, john at