macros v. inline functions

This may be a topic worth considering at "the upcoming Perl 5 Core Hackathon".

It would be useful to have guidelines for when we should prefer to add
inline functions rather than macros.

I suspect we could be using them a lot more than we do, but I don't know
how many platforms still have insufficient capabilities to support them.

Macros suffer from lack of types on arguments, risk of multiple evaluation,
and opacity in debuggers. They also do not give compilers a choice whether
to inline them, so may lead to less efficient code.

Inline functions cannot do everything macros can, but where they can do
what is needed the only drawback I know of is that on a platform that
does not support them you'll get much less efficient code.

Hugo
0
hv
8/12/2019 9:55:31 AM
perl.perl5.porters 48115 articles. 1 followers. Follow

4 Replies
74 Views

Similar Articles

[PageSpeed] 11

On Mon, Aug 12, 2019 at 10:55:31AM +0100, hv@crypt.org wrote:
> This may be a topic worth considering at "the upcoming Perl 5 Core Hackathon".
> 
> It would be useful to have guidelines for when we should prefer to add
> inline functions rather than macros.
> 
> I suspect we could be using them a lot more than we do, but I don't know
> how many platforms still have insufficient capabilities to support them.
> 
> Macros suffer from lack of types on arguments, risk of multiple evaluation,
> and opacity in debuggers. They also do not give compilers a choice whether
> to inline them, so may lead to less efficient code.
> 
> Inline functions cannot do everything macros can, but where they can do
> what is needed the only drawback I know of is that on a platform that
> does not support them you'll get much less efficient code.

I agree.

I expect that given how deep some of our macros are, switching to
inline functions in many cases could result in smaller code with
little performance impact, simply from the compiler not inlining
functions in UNLIKELY() code.

I should probably have used an inline function for SANE_ERRSV.

Tony
0
tony
8/21/2019 1:54:00 AM
More on this:

I have started an experiment to fix up the SvTRUE macro at least,
because I always get annoyed that

  SvTRUE(POPs)

doesn't DWIM. I've got a smoke-me branch that turns it into an inline
function, and this seems to work fine on the smokers*. I've even
manually tested it on one of Tux's HPUX 11 boxes and it seems fine.

  https://github.com/Perl/perl5/tree/smoke-me/leonerd/inline-function-SvTRUE

Is there any reason now why I shouldn't merge this up to blead and
generally finish/tidy it off? I'll stick to just the SvTRUE family for
now, but I think even just those could be made neater and tidier, as
the first step into trying to do a lot more of them.

Anyone got any other interesting platforms I should be looking at?


[*]: Give or take a lot of FAIL noise e.g. things to do with longdouble
or other platform-specific problems, but I think all of those failures
are unrelated to this change. We should look into those though as they
make this sort of test less useful.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
11/13/2019 5:16:50 PM
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
:More on this:
:
:I have started an experiment to fix up the SvTRUE macro at least,
:because I always get annoyed that
:
:  SvTRUE(POPs)
:
:doesn't DWIM. I've got a smoke-me branch that turns it into an inline
:function, and this seems to work fine on the smokers*. I've even
:manually tested it on one of Tux's HPUX 11 boxes and it seems fine.
:
:  https://github.com/Perl/perl5/tree/smoke-me/leonerd/inline-function-SvTRUE
:
:Is there any reason now why I shouldn't merge this up to blead and
:generally finish/tidy it off? I'll stick to just the SvTRUE family for
:now, but I think even just those could be made neater and tidier, as
:the first step into trying to do a lot more of them.

Does replacing the macro with a function break binary compatibility?
If so, I don't remember what caveats apply, or what the procedure is.

Hugo
0
hv
11/13/2019 9:08:54 PM
On 11/13/19 2:08 PM, hv@crypt.org wrote:
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
> :More on this:
> :
> :I have started an experiment to fix up the SvTRUE macro at least,
> :because I always get annoyed that
> :
> :  SvTRUE(POPs)
> :
> :doesn't DWIM. I've got a smoke-me branch that turns it into an inline
> :function, and this seems to work fine on the smokers*. I've even
> :manually tested it on one of Tux's HPUX 11 boxes and it seems fine.
> :
> :  https://github.com/Perl/perl5/tree/smoke-me/leonerd/inline-function-SvTRUE
> :
> :Is there any reason now why I shouldn't merge this up to blead and
> :generally finish/tidy it off? I'll stick to just the SvTRUE family for
> :now, but I think even just those could be made neater and tidier, as
> :the first step into trying to do a lot more of them.
> 
> Does replacing the macro with a function break binary compatibility?
> If so, I don't remember what caveats apply, or what the procedure is.
> 
I don't believe there is any guarantee of backwards binary compatibility 
across major releases; only in maint ones.
0
public
11/14/2019 3:47:47 PM
Reply: