3

Is it possible in C++ to write a macro, which AFTER expansion will output a backslash sign?

Right now I'm using a code:

#define SOME_ENUM(XX) \
    XX(FirstValue,) \
    XX(SecondValue,) \
    XX(SomeOtherValue,=50) \
    XX(OneMoreValue,=100) \

but I want to write a macro, which will generate the code above, so I want to be able to write:

ENUM_BEGIN(name) // it should output: #define SOME_ENUM(XX) \
ENUM(ONE)        // it should output: XX(ONE,) \
//...

But I was not able to write a macro like ENUM_BEGIN, because it should expand to something with backslash on the end. Is it possible in C++?

Wojciech Danilo
  • 11,573
  • 17
  • 66
  • 132
  • 4
    If you really want to render your code unreadable, there are easier ways than this. – Jerry Coffin Mar 26 '13 at 19:02
  • 1
    I don't think the preprocessor will process a preprocessor directive that is the result of a macro. Also, writing that last sentence leads me to believe this may be bad design... – lcs Mar 26 '13 at 19:06
  • Jerry I want my code to **be** readible - I'm trying to improove the solution found here: http://stackoverflow.com/questions/147267/easy-way-to-use-variables-of-enum-types-as-string-in-c . – Wojciech Danilo Mar 26 '13 at 19:07
  • Is there any C++ macro expansion that **needs** an unquoted backslash to begin with? – Drew Dormann Mar 26 '13 at 19:08
  • What functionality are you trying to accomplish? [You cannot define a macro within another macro](http://stackoverflow.com/questions/5144042/c-define-a-define). What you are more likely looking for is static polymorphism through templates. – IdeaHat Mar 26 '13 at 19:16
  • 1
    @danilo2: I didn't really figure the *intent* was to produce an unreadable mess -- but I think that's a nearly inevitable *result* of where you're heading anyway. IOW, it was my idea of a subtle hint that I think what you're doing is more likely to add to the problem than produce a real solution. – Jerry Coffin Mar 26 '13 at 19:16

2 Answers2

1

No, it is not possible. Relevant to this would be §2.2.1, translation phase 2 described in ISO/IEC 14882:2011(E):

Each instance of a backslash character () immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice. If, as a result, a character sequence that matches the syntax of a universal-character-name is produced, the behavior is undefined. A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file.

Basically what will happen is the \\\n (where the \n is physically in the source, not an escape), will be treated as a \ character, followed by a line splice. The remaining \ will most likely result in a syntax error (there may be situations where it is legal, but I don't currently see any), and not treated during subsequent translation phases as a line splice (line splicing occurs in only phase #2).

Nathan Ernst
  • 4,540
  • 25
  • 38
0

I haven't found any documentation for it, but I would've thought that you could just do \\ and you'll generate a backslash.

However, in my research, I see that may not be the biggest thing you'll have to deal with. As millsj just commented, you'll have issues outputting the # in your ENUM_BEGIN. See Escaping a # symbol in a #define macro? .

Community
  • 1
  • 1
Scott Mermelstein
  • 15,174
  • 4
  • 48
  • 76
  • The link you posted has got a very important information: "You can't do that. Preprocessor directives are recognized before macro expansion; if the macro expands into something that looks like a preprocessor directive, that directive will not be recognized" So it is not possible. Thank you – Wojciech Danilo Mar 26 '13 at 19:09