> From: Sebastian Wittmeier <wittmeier_at_[hidden]>

> A) Each (or only the more complex) C++ expression leave the F string and resume it, everything is concateated, e.g.:
> print( X"SOME_FLAG = {" SOME_FLAG ":x}" );

I'm being nit-picky, but just to be clear... technically it would have to be:

    print( X"SOME_FLAG = {" #SOME_FLAG ":x}" );

If the SOME_FLAG was not already a literal string.

> B) simple specific escaping
> print( X"SOME_FLAG = { ####SOME_FLAG####:x }" );
> C) complete escaping
> print( X"SOME_FLAG = { a ? \"\\\\\" \\: \"\\:\" :x }" ); // for a ? "\" : ":"
> D) Flexible escaping similar to raw string literals
> print( X"SOME_FLAG = {dch{ a ? b : c :dchx }dch" );
> E) have the preprocessor parse the string itself
> print( X"SOME_FLAG = { SOME_FLAG:x}" );
> - most difficult to sync WG21/WG14

Yeah... so, in terms of macro expansion, options A-D all look pretty horrible to me, except option-E which seems unlikely to happen.

For example with option-A: not only is it ugly, but it already requires the programmer to recognize the fact that the macro needs to be separated to resolve properly.

If they recognize that, then we're not avoiding the "surprise" factor to begin with. They can just use the current functions today:

    print("SOME_FLAG = {}", #SOME_FLAG);

---

The concern with macros, at least to me, is that a programmer would be surprised this doesn't do what it looks like it should do:

    print( X"SOME_FLAG = { SOME_FLAG:x }" );

Or a more egregious example is one that someone raised to me offline:

    print( X"value = { abs(x) }" );

because abs() is a C-function and allowed to be implemented as a macro, and has been in practice (I think?).

-hadriel



Juniper Public