Thread (113 messages) flat view 113 messages, 3 authors, 2016-06-15

Re: [PATCH 01/72] gettext.h: add no-op _() and N_() wrappers

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2016-06-15 22:50:37

On Sun, Feb 20, 2011 at 03:01, Jonathan Nieder [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Ævar Arnfjörð Bjarmason wrote:
quoted
Add a new header called gettext.h which is currently a no-op.
Thanks.  I'd suggest squashing this with patch #2 (#including
gettext.h in cache.h).
quoted
--- /dev/null
+++ b/gettext.h
@@ -0,0 +1,9 @@
+/*
+ * Copyright (c) 2010 Ævar Arnfjörð Bjarmason
Is such a simple header file copyrightable?  But I don't mind.
quoted
+ *
+ * This is a skeleton no-op implementation of gettext for Git. It'll
+ * be replaced by something that uses libintl.h and wraps gettext() in
+ * a future patch series.
+ */
+#define N_(s) (s)
Might be nice to make this an inline function, for type safety.
quoted
+#define _(s) (s)
This one can't be a function, though, since it needs to transform
literals to literals.

Some possible tweaks:

 - protect against double inclusion
 - make _ into a function
 - add a comment vaguely explaining N_
 - avoid confusing errors if some other header has pre-defined _.

Signed-off-by: Jonathan Nieder <redacted>
---
 gettext.h |   19 +++++++++++++++++--
 1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/gettext.h b/gettext.h
index c68bbe9..2f806cb 100644
--- a/gettext.h
+++ b/gettext.h
@@ -1,3 +1,10 @@
+#ifndef GETTEXT_H
+#define GETTEXT_H
+
+#ifdef _
+#error "namespace conflict: '_' is pre-defined?"
+#endif
+
 /*
 * Copyright (c) 2010 Ævar Arnfjörð Bjarmason
 *
@@ -5,5 +12,13 @@
 * be replaced by something that uses libintl.h and wraps gettext() in
 * a future patch series.
 */
-#define N_(s) (s)
-#define _(s) (s)
+
+static inline const char *_(const char *msgid)
+{
+       return msgid;
+}
+
+/* Mark msgid for translation but do not translate it. */
+#define N_(msgid) (msgid)
+
+#endif
Thanks for this. This was raised earlier in the discussion for this
series (by you, IIRC). I've considered it, and while I see your point
(type safety = good) I think I like my way of doing it better.

The _() macro/function is usually a macro and not a function. The good
thing about this is that I can prove that it's a no-op on all
compilers, whereas if it's an inline function (stupid) compilers will
actually make it into a function, which'll result in overhead,
which'll mean I can't advertise this series as a "no-op" anymore.

Check out some of the recent work in perl.git for reference. There's
now a probe in perl which check is the compiler can *really* handle
inline functions, and if not perl will fall back on using macros.

I'd rather not use inline functions for every string in Git without
such a probe, especially since it's for a very marginal gain. Using
_() for non-strings isn't going to make it past the list, and if it's
used with e.g. multiple arguments compilers will already whine about
it.

So that's why I didn't do it. But if everyone else feels strongly
about it I'll change my mind, I don't care *that* much about it, but
I'd prefer a macro.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help