"Keith OHara" <k-ohara5...@oco.net> writes:
> If you can define the trampoline as a static member of the class whose
> member function is being called, that will be less surprising.
The whole point is that the trampoline will be provided automatically.
Having to define it manually would defeat the point, in particular since
a number of classes (contexts, iterators, and stuff) define their own
listener.
So it would need to be either a static member of a common base class
(which is more or less what it is now). Or it needs to be a global
template function not specific to any class. The templates need to
depend on the member function pointer that they are planning to hook
into. I think that C++11 would likely provide the tools in order to get
along for a single definition covering all argument lists.
But manually covering for a number of argument list types should be
fine, and it means that it is easy to throw in specializations calling
protect_event or whatever else.
> It might be a bit ugly to have the boiler-plate code in each derived
> class that uses the mechanism, but the boilerplate is recognizable if
> we can see it all at once.
I think that one global definition should be sufficient here. It can
likely be tucked with lily-guile.hh and any more specific
spezializations can be placed in the corresponding header files.
> LY_DECLARE_SMOB_APPLY_INIT(smob_apply_trampoline, 1, 0, 0) static SCM
> smob_apply_trampoline(SCM self, SCM arg) { return
> unsmob(self)->listen(arg); } SCM listen(SCM ev) { ...}
Oh, you were talking about the SMOB_APPLY templates here? I was
thinking of the Listener trampolines in Callback_wrapper. If you want
to do a version of the smob_apply stuff working without overloading on
the member function type, the solution for that would be to make the
total number of arguments an explicit template parameter (in a similar
vein to how the argument _type_ to the function pointer in the
Callback_wrapper trampolines is currently a template parameter). You'll
still need to specialize for each number of parameters though.
At any rate: the more manual work one has to do rather than have the
compiler pick a matching function, the more opaque the whole stuff gets.
People running the newest version of LilyPond will rarely be running it
on a system that has been out of maintenance for several years.
With regard to the _placement_ of the "apply" trampoline code: note that
SMOB_APPLY is used on a variety of smob types, not just Smob, and its
operation is fixed to a particular GUILE smob type. So its definition
cannot be overriden in derived classes apart from overriding a virtual
function from the base class. So as it is tied to one smob_id, placing
it with Smob_base<Super> and connecting it with Super is pretty much the
only sane manner to do it.
So while I am not particularly enthused about the current trampoline
code location for Callback_wrapper/Listener use (and the above
discussion refers to alternatives for that), the smob_apply stuff is
actually where it belongs.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
