OK, I see.
The reason is that our parser(preprocessor) don't do a semantic check on every identifier, CB has macro expansion method, but it does not expand macro usage always.
For example, when the parser see a identifier like token:
It just see it as a simple type name or a variable name.
But what a compiler(gcc) do is to check every identifier to see whether it is a macro usage, and if it is true, then expand the macro.
I think we can enable it, but it will let the parser a bit slower, as you can think, checking of every identifier token takes much time, right?
Here is a test (cctest) file that we can test your request:
/* x macro
* https://en.wikipedia.org/wiki/X_Macro
*/
#define LIST_OF_VARIABLES \
X(value1) \
X(value2) \
X(value3)
#define X(name) int name;
LIST_OF_VARIABLES
#undef X
// val //value1,value2,value3
Currently, it get failed, but if we try to expand the LIST_OF_VARIABLES, I think it should be OK.
Also, for some enum definition:
// test parsing of enumerator assignments
#define SHIFT(_x) (1 << (_x))
enum PowerEnum
{
powFirst = SHIFT(1),
powSecond = SHIFT(2),
powThird = SHIFT(3),
powFourth = SHIFT(4),
powFifth = SHIFT(5)
};
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2014-03-05110639_zps80b175ac.png)
You see, the tip show a value 32, which is calculated "1<<5".
Maybe, we can trigger macro expansion on a token which is totally capital characters?
ollydbg
I think we can enable it, but it will let the parser a bit slower, as you can think, checking of every identifier token takes much time, right?
Thanks for your reply.
Yes, of course. Maybe we could put it into low priority queue of parsing and let high priority one goes first.
Actually, I don't mind wait for 10 mins or more and in the meantime I could write other codes because typing
each characters each time is really annoying without autocomplete.
ollydbg
Maybe, we can trigger macro expansion on a token which is totally capital characters?
X Macros have some coding patterns but sometimes they vary. In case of resolving the same problem twice,
dealing them both, pattern and no pattern, and put the pattern one into high priority may be a good idea.
Huki
This feature is present in my cc_parser_general.patch (checks each identifier for preprocessor token if the m_Options.parseComplexMacros is on). It's a rather long patch with several other features, I'm trying to get the small ones (and bug fixes) in first.
Thanks for your reply.
I wrote another example. It may be helpful to test the patch.
#include <stdio.h>
#include <stdlib.h>
/* X Macro */
#define LEVEL_LIST(XX) \
XX(1, all, All) \
XX(3, debug, Debug) \
XX(5, info, Info) \
XX(7, warn, Warning) \
XX(9, error, Error) \
XX(12, fatal, FatalFailure) \
XX(15, off, Off) \
/* Example: Define a enumeration. */
#define XX(idx, name, msg, ...) level_##name = idx,
typedef enum {
LEVEL_LIST(XX)
} level_e;
#undef XX
/* Example: Define an array. */
#define XX(idx, name, msg, ...) [idx] = #msg,
static const char *g_levelmsg_list[] = {
LEVEL_LIST(XX)
};
#undef XX
int main()
{
printf("%s:%d, %s\n", __FUNCTION__, __LINE__, g_levelmsg_list[level_info]);
return EXIT_SUCCESS;
}