#57 typedef enum is ignored

[Toger]

Test case:
test.h:

typedef enum{Test} TestEnum;

This is unnecessary and uncommon in C++ but completely legal. It is common in C and I need to parse some code with C origin.

This is how I parse the code:

import CppHeaderParser
ast = CppHeaderParser.CppHeader("test.h")
for a in ast.__dict__:
    print(a + ": " + str(getattr(ast, a)))

The script runs successfully and prints lots of empty lists. The output does not contain "TestEnum" at all.

[Jashua Cloutier]

80% of this project has been dealing with obscure C/C++ :)

I'll try to take care of this this weekend.

[Jashua Cloutier]

Fixed in commit 129:98b9034810f5

[Toger]

Fix works in my test cases. Thank you for the fast solution.

Minor nitpick: There seems to be no distinction between

enum TestEnum{Test};

and

typedef enum {Test} TestEnum;

For C++ there is no difference, for C there is. Guess it is my fault for using a C++ Header Parser on C headers.

[Jashua Cloutier]

I will have to investigate this. What practical purpose do you have for distinguishing between the 2?

[Toger]

The end result will be an RPC generator. It will read a header file and create an implementation for each declared function that serializes the arguments and send a function ID and the arguments over a network. It will also generate code that deserializes the string and calls the appropriate function on the other side. For that I need to know the size of each data type in bytes with some trickiness for pointers.

Since I am generating code that has to compile I may need to spell out the type of an enum. For the previous example it would be either "enum TestEnum" or "TestEnum" depending on if the typedef trick was used.

Currently I am trying to figure out the size of enums using their value range. A feature that would really help me would be to calculate constants:

const auto answer = 42;
enum Complex{V1 = -100, V2 = (V1 << 3) / answer};

C++ Header Parser would ideally say something like "enum { "name": "enum Complex", "values" : [("V1", -100), ("V2", -19)]}". Currently the parser swallows the "/". Unfortunately this will not work anymore as soon as "sizeof(int)" is involved.

[Jashua Cloutier]

For swallowing the / you may want to create a bug on that. But I dont anticipate that I will solve problems like converting "(V1 << 3) / answer" to -19. But there may be a way to say "(V1 << 3) / answer" and get that. Did you look in the debug field?

Oddly enough, I did something very similar to what you are doing which is why I created this in the first place.

[Jashua Cloutier]

as of 132:9c2bccd467b9 the '/' shouldnt get lost with your Complex example. It will correctly be represented as

{'values': [{'name': 'V1', 'value': '- 100'}, {'name': 'V2', 'value': '( V1 << 3 ) / answer'}], 'line_number': 6, 'namespace': '', 'type': <type 'int'="">, 'name': 'Complex'}

[Jashua Cloutier]

With 133:9c58cec5d440 you can check an enums 'typedef' field to see if it was created with a typedef declaration.

[Toger]

The typedef field works well, thanks a lot. I had a similar issue with struct S{int i;}; vs typedef struct{int i;} S;. Fortunately either one is parsed correctly and using classes[name_of_struct]["properties"]["public"]["property_of_class"] == name_of_struct it is possible to distinguish the typedef version from the regular version. Maybe there is an easier way or one can be added, but this works. I will try to talk my employer into releasing the RPC generator as open source so there is a chance it can be of value to you / others, too.