Re: Master fails to compile

[David Kastrup]

"Keith OHara" <address@hidden> writes:

> 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.

Which he got updated with a backport.

> 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.

Well, using no longer supported systems with network access (and it's
pretty hard to work on current LilyPond source without network access)
is a security nightmare.  Old GNU/Linux installations are actually
pretty popular as mail hubs for malware distribution.

> 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.

Smob_base may not be the best place.  I remember wanting to put it in
Dispatcher itself at first and I got some private/protected thing in the
way.  But it might make more sense to pierce the encapsulation with some
sort of "friend" declaration (if unavoidable) rather than move the whole
functionality there.

Never attribute to design what may equally well be attributed to
stupidity.

But this detail does not actually bear any relation to the GCC version
needed for the template instantiation.

> 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.

The trampolining technique is not restricted to scm_set_smob_apply.

> 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.

The choice to use a non-static member function in the user-serviceable
parts and delegating the rest to the compiler's care is not arbitrary.
It makes the code more readable and manageable.  The idiom of non-static
member functions and the implied use of an instance-specific
this-pointer is one of the earliest core tenets of C++.

Doing the real work via template/C++ mechanisms rather than with some
hand-cooked C macros makes this approach less LilyPond-specific and thus
lowers barriers of entry for people new to our code base.

-- 
David Kastrup