(C/C++) how to create a macro that accepts the increment operator - c++

to make my question precise i would like to create a macro that accepts as variable ++ and pastes it with another variable. In code:
#define MYMACRO(A, OP) /* .... */
and then if i write in the source file
MYMACRO(this->var, ++)
the preprocessor should paste in the code
this->var++;
When i am trying to define the macro as A##OP , it provides the following error:
pasting "++" and "var" does not give a valid preprocessing token
Is it possible to do what i am trying?
thanks in advance for the answer

You don't need the ## token pasting operator, because you're not trying to combine the parameters into a single token. Just use:
#define MYMACRO(a, op) (a)op;

You just need to combine the tokens like this:
#define MYMACRO(a, incrdecr) (a)incrdecr

Related

Resharper : subtituate macro with multi-line code

Is it possible to make Resharper Substituate macro call in separate-lines mode?
Example
I have this code :-
#define TEST(T) int T=5; \
T++;
TEST(apple);
If I click
Substituate macro call and all nested calls like this :-
The line TEST(apple); will become :-
int apple=5; apple++;;
I hope there is an option to make the result be 2 separate lines :-
int apple=5;
apple++;;
Other notes
I know that macro with \ is finally interpreted as a single line,
but it would be nice if there is an option to show it as many lines for eye-candy.
(Even it may break the macro behavior, e.g. those with __LINE__ )
It would be useful for debugging for a 10+ lines macro.
It's not possible at the moment, but you can always select the resulting code after a macro substitution and invoke "Reformat Code" (Ctrl+Alt+Enter) to make it readable.

Preprocessing simple integer arithmetic with cpp

I have a following input file:
#define __SIZE_K(x) (x * 1024)
#define DT_FLASH_SIZE __SIZE_K(128)
reg = <0x08000000 DT_FLASH_SIZE>;
If I run that through a preprocessor I get this:
$ cpp -x assembler-with-cpp input.dts -E -P
reg = <0x08000000 (128 * 1024)>;
If it possible to get the macro fully evaluated? I would like to have:
reg = <0x08000000 131072>;
I would like to have devicetree source files "fully-preprocessed" and I would prefer to do this entirely in the preprocessor, but I'm not sure this is possible... The final devicetree consists of multiple files, some of which define the layout, some are headers with macros and various values depending on selected chip.
If it possible to get the macro fully evaluated?
Theoretically, yes. But it's not usable in the context you want to use it.
Preprocessor is a simple text replacement tool. It replaces one text for the other. First, you have to implement a table of all possible combinations of replacements:
#define MUL_1_1 1
#define MUL_1_2 2
#define MUL_1_3 3
// etc. for **billions** of lines
#define MUL_128_1024 the_result_here
// etc.
After those bilions of lines, you can finally write:
#define MUL_(a, b) MUL_##a##_##b
#define MUL(a, b) MUL_(a, b)
After that you can do:
#define __SIZE_K(x) MUL(x, 1024)
You can use a library - like P99_MUL or BOOST_PP_MUL - and they are basically implemented in almost the same way, with a lot of optimizations to shorten the list.
There is no point in using specifically C preprocessor in this context anyway. Use M4 or Python's Jinja2 or PHP - a full programming language, instead of some limited preprocessing C tool.

syntax error, unexpected token, expecting end of file

I get the following error when i run my Parser file ( binary got after compiling Flex/Bison files).
error: syntax error, unexpected TKN_PRIMARY, expecting end of file
Here is rule defined in flex code:
<PRIMARY_MME_STATE>{number} {
lexVal = YYText();
std::cout<<"PRIMARY MME --> "<<lexVal<<std::endl;
yylval->strVal = new std::string(lexVal);
return token::TKN_PRIMARYMME;
}
And my understanding is that since value of TKN_PRIMARY is zero ( which is the value defined for END %token END 0 "end of file") Instead of returning TKN_PRIMARY , it is expecting token END to be returned. Please comment if my understanding is correct . And Also how to tackle this issue.
If TKN_PRIMARY and END have the same value (or, in general, if any two different tokens have the same value), then the bison parser is going to act in unpredictable ways.
Quoting the bison manual:
It is generally best, however, to let Bison choose the numeric codes for
all token types. Bison will automatically select codes that don't
conflict with each other or with normal characters.
I think that's definitely the best way of dealing with the problem.

#define directive with multiple replacements?

I am relatively new to programming, and I am trying to learn to use wxWidgets in C++ (with Visual Studio 2010).
I was looking through the wxWidgets header file "app.h" and I see some #define directives that I can't understand. Here is an example:
#define wxIMPLEMENT_APP(appname) \
wxIMPLEMENT_WX_THEME_SUPPORT \
wxIMPLEMENT_APP_NO_THEMES(appname)"
I'm used to seeing #define with one "identifier" and one "replacement", so I can't understand if this macro has two "identifiers" (wxIMPLEMENT_APP(appname) and wxIMPLEMENT_WX_THEME_SUPPORT) and one "replacement" (wxIMPLEMENT_APP_NO_THEMES (appname)), or one "identifier" (wxIMPLEMENT_APP(appname)) and two "replacements" (wxIMPLEMENT_WX_THEME_SUPPORT and wxIMPLEMENT_APP_NO_THEMES(appname)).
How am I to understand this macro?
I tried looking online and in text books, searching under "macros", "pre-processor directives", "text replacement macros", "#define directive", and similar, but I could not find any examples with explanation that look like the one I have here.
This preprocessor macro has a single replacement split across multiple lines. The \ at the end of the line lets you write a single "logical" line on multiple lines of text.
Everything that follows wxIMPLEMENT_APP(appname) will be placed in the text of the program when wxIMPLEMENT_APP(appname) pattern is matched; presumably, both these definitions will be further processed by the preprocessor, because they look like references to other macro definitions.

How to write a bison file to automatically use a token enumeration list define in a C header file?

I am trying to build a parser with Bison/Yacc to be able to parse a flow of token done by another module. The tokens are already listed in a enumeration type as follow:
// C++ header file
enum token_id {
TokenType1 = 0x10000000,
TokenType2 = 0x11000000,
TokenType3 = 0x11100000,
//... and the list go on with about 200/300 line
};
I have gone through the documentation of bison many times but I couldn't find a better solution than copying each token in the Bison file like this:
/* Bison/Yacc file */
%token TokenType1 0x10000000
%token TokenType2 0x11000000
%token TokenType3 0x11100000
//...
If I have to do it like that, It will become pretty hard to maintain the file if the other module specification change (which happen quite oftenly).
Could you please tell me how to do it, or point me in the good direction (any idea/comment is welcome). It would greatly help me! Thanks in advance.
Instead of doing :
/* Bison/Yacc file */
%token TokenType1 0x10000000
%token TokenType2 0x11000000
%token TokenType3 0x11100000
//...
You just need to include the file with the token type in the declaration part
#include "mytoken_enum.h"
// ...
%token TokenType1
%token TokenType2
%token TokenType3
//...
EDIT: This can not be done:
As you see from the numbers above,
Bison just numbers the tokens
sequentially, and it is used shifted
in parser lookup tables as indices,
for speed simply. So Bison does not
support that, I feel sure, and it
would not be easy to fit with the
implementation model.
Just need to wrapper to convert the real token to yacc/bison token (eg: via yylex())
The obvious method would be a small utility to convert from one format to the other. If you're really making changes quite frequently, you might even consider storing the names and values in something like a SQL database, and write a couple of queries to produce the output in the correct format for each tool.
select token_name, '=' token_number ','
from token_table
select '%token ', token_name, ' ', token_number
from token_table
The first would require a bit of massaging, such as adding the 'enum token_id {" to the beginning, and "};" to the end, but you get the general idea. Of course, there are lots of alternatives -- XML, CSV, etc., but the general idea remains the same: store and edit as close to raw data as possible, and automate adding the extra "stuff" necessary to keep the tools happy.