Re: Master fails to compile

[Keith OHara]

On Mon, 25 May 2015 23:10:17 -0700, David Kastrup <address@hidden> wrote:

> Keith OHara <address@hidden> writes:
>
> > If I can't get the dependencies worked out I'll be tempted to skip
> > the macro and use scm_call_1() through scm_call_3() in place of each
> > of the three macro expansions.
>
> Why?  Seriously.  10.04 is not even supported by Ubuntu itself any more.

Phil has the Ubuntu.  I had an old RedHat installation with gcc updated as far 
as I could to 4.6.  In the next few weeks I'll find some reasonably-modern 
linux.

The tricky bit about the function template in Smob_base
  template <SCM (Super::*pmf)(void)> static SCM smob_trampoline (SCM self)
is the way it creates functions in Smob_base that call member functions of the 
derived classes like Listener.  Following what happens requires a lot of 
flipping back and forth between header files.

It took me quite a while to figure out why you register with scm_set_smob_apply() a 
static member function of Smob_base<Listener> rather rather than something in 
Listener directly.  After a while I concluded that the goal was to put the trampoline 
code all in one place.  This seemed odd as the general-case (four cases) trampoline 
outnumbered the use cases.

You might want to expand the macro in-place, and follow each expansion with the 
definition of the trampoline function  --  or let the routine implementing "apply 
smob" be a static member function, so it serves as its own trampoline.  Hundreds of 
times, even.  Once for every Smob-derived class, even.

It's just the balance between code duplication and obfuscation.

> I have a patch cooking that will convert hundreds of Scheme callbacks to
> member functions with that technique.  Part of the reason is to get
> argument type checks in for stuff like
>
> (ly:grob::stencil-height 0)
>
> which just segfaults right now.  Having a member function instead of a
> static member makes the code simpler while the static template generated
> by this technique does the typechecking while creating a this-pointer
> from an SCM.  And if you call the member function via C++ with an
> existing instance pointer, you bypass the typechecking.