Re: [PATCH] Allow inserting non-BMP characters

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 26 Dec 2017 18:50:46 +0000
> Cc: emacs-devel@gnu.org, phst@google.com
> 
>  I don't think we have a policy to prefer inline functions to macros,
>  and I don't think we should have such a policy.  We use inline
>  functions when that's necessary, but we don't in general prefer them.
>  They have their own problems, see the comments in lisp.h for some of
>  that.
> 
> Thanks, the only discussion I saw there was about some performance issues:

Let me make it more clear:

Macros are faster in non-optimized builds (that's why we have such a
complex setup with them in lisp.h).

Macros are also better for debugging, especially when you debug a core
file.  Invoking a function when debugging needs a running process, so
it cannot be done when debugging a core file.  And sometimes the
compiler doesn't keep a non-inlined version of an inline function, so
it cannot be called from the debugger at all.

On the downside, macros can be less readable when they are complex,
and have additional problems when you need local variables.  (None of
that is relevant to the issue at hand.)

>  > and don't seem to be correct either (what about a value such as 0x11DC00?).
> 
>  ??? They care correct for UTF-16 sequences, which are 16-bit numbers.
>  If you need to augment them by testing the high-order bits to be zero
>  in your case, that's okay, but I don't see any need for introducing
>  similar but different functionality.
> 
> I'd be OK with using the macros since they already exist, but I wouldn't want to touch them without converting
> them to functions first, and for using them in nsterm.m I'd have to move them around.

You don't need to convert the macros to anything, just add a test that
you need, as in

   if (c < 0xFFFF && UTF_16_HIGH_SURROGATE_P (c))
     ...

>  > No new macros please if we can avoid it. Functions are strictly better.
> 
>  Sorry, I disagree.  Each has its advantages, and on balance I find
>  macros to be slightly better, certainly not worse.  There's no need to
>  avoid them in C.
> 
> I disagree, see e.g. https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html and many other sources.
> Sometimes macros are unavoidable, but not here.

See above.

>  Yes, but why do you first copy the input into a separate buffer?  Why
>  not convert each UTF-16 sequence separately, as you go through the
>  loop?
> 
> Message (method) invocations in Objective-C have high overhead because they are late-bound. Therefore it is
> advisable to minimize the number of messages sent.
> https://developer.apple.com/documentation/foundation/nsstring/1408720-getcharacters?language=objc also
> indicates that a (properly implemented) getCharacters call is faster than calling characterAtIndex in a loop.

Is that a fact, or should we measure that?