[Lumiera] NoBug: minor problem with C++11 compliance

Christian Thaeter ct at pipapo.org
Tue May 6 16:37:39 CEST 2014

Am Mon, 17 Mar 2014 02:38:51 +0100
schrieb Ichthyostega <prg at ichthyostega.de>:

> Hello Christian,
> currently, I'm working towards the switch to C++11 for the Lumiera
> codebase. There is a nasty but basically IMHO harmless problem with
> NoBug: C++11 introduced user defined string literals and as such
> needed to clarify how string literals are tokenised. Unfortunately,
> for NoBug this means that
> ""__VA_ARGS__
> is now treated as a single token (which consequently is left
> unexpanded by the preprocessor). To restore the old behaviour, we
> need to clarify by inserting whitespace
> "" __VA_ARGS__
> Hopefully this breaks nothing else.
> You'll find the proposed fix in commit 9ba2e948a7
> See here:
> http://git.lumiera.org/gitweb?p=debian/nobug;a=commit;h=9ba2e948a7c95e28d156823174bdca187db679f9

I am just merging it and stumbled on:

@@ -655,12 +655,12 @@
   low level logging handler
-  Note: all fmt concatenations use an empty string ""__VA_ARG__
+  Note: all fmt concatenations use an empty string "" __VA_ARG__
         except this one which must use a single space " " before
__VA_ARGS__ for formatting the log message correctly (and silence a gcc warning)

You added a space there? for what purpose, it breaks the tests and the
output here, did I miss something? what gcc warning?

btw: the whole ', "" __VA_ARGS__' stuff is just to ensure that the cases
where __VA_ARGS__ is empty AND where it is string-literal are handled
in a ansi conforming way. If __VA_ARGS__ is empty then a macro
expansion FOO(something,) with a trailing comma would be illegal. Gcc
has a extension to remove the comma with the ', ## __VA_ARGS__'
syntax, but thats not Standard to my knowledge. Neither does this catch
type errors when something else but a string is given.


> Cheers,
> Hermann

More information about the Lumiera mailing list