🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Parsing a .h header file

Started by
4 comments, last by hehenoobhehe 20 years, 8 months ago
Any suggestions for how to parse a header file that contains the interface for a class that must be generated using PERL(or any thing else, I dont know hence I dont suggest anything other than PERL at this juncture). I guess this means being able to extract information like: -Function Declarations -Arguments And then be able to use this information for creating a C++ class that implements these methods Any suggestions on how to do this or where to look for appropriate information are welcome. Thanks. PS.Posting this as a seperate question (in addition to the earlier one related to the same) because I think the earlier post doesnt explain well enough what Im trying to achieve in the first place, [edited by - hehenoobhehe on October 22, 2003 3:17:48 AM]
Advertisement
You mean, like SWIG does?

How appropriate. You fight like a cow.
quote: Original post by Sneftel
You mean, like SWIG does?

How appropriate. You fight like a cow.



There is a lot that I dont understand from what I read on the SWIG website.

All I want to do is to use a header file to generate some C++ code from it namely a class declaration and function definitions complete with arguments etc and some defunct code that I could then use to generate more code, namely, this

1) Have a header file blah.h that contains the interface

2) Generate a .cpp file from it that has the class declaration and function definitions with defunct/default code and some placeholders/tags(layman language used here owing to lack of specuialized knowldge of PERL or scripting in general) that are to be replaced in Step 3

3) Use the file from Step 2 and replace the placeholders with some information that is provided (by means of an input config file/command line/whatever other means) and must be replaced uniformally in the entire file(from Step 2)

Requirements that MUST be met from the FINAL PROCESSED OUTPUT FILE from Step 3 are:
1) The length of each line of code (that can be compiled by a standard C++ compiler) must NOT exceed 78 characters
2) Indentation and other standard formatting features must be retained and no user intervention must be needed in order to beautify or standardize the code to something that is normally acceptable as code that can be accpeted in a code repository.
3) Last, stating the obvious of course: the code SHOULD be capable of being compiled by a C++ compiler.

I hope I have come up with a better description of the problem at hand.

Do you think I need to use SWIG for this purpose and add complexity to the problem?

Maybe I dont understand what SWIG is and hence I dont see the usage of it in this situation. I would appreciate if you would comment on the same,.

Thanks very much for the response. Much appreciated.


[edited by - hehenoobhehe on October 22, 2003 5:00:40 AM]
You might want to have a look at boost::spirit, from what I can remember it has some examples of how to parse C++ code in an Object-Oriented way, and then to attach actions to each rule.

If parsing is the job you need to do you might also look at flex and bison (lex and yacc). There should be plenty of freely available C++ language grammars which should be ready to use.


[edited by - XXX_Andrew_XXX on October 22, 2003 5:49:38 AM]
With reference to my problem that I have described here:
A possible solution to the problem *could* be :

1) I use the same method I use now to create a tokenzied sorta intermediate file from the header file complete with all the information that I need to be able to furnish a class declaration and a class definition.Call this File A

Use File A as an input file to further process the tokens etc and produce another file that has tags/tokens whatever else that I need for stuff like:

-function names

-function params

return values

and so on WITHOUT any formatting.CAll it File B
3)Use File B and parse each token to get File C. While priting out File C, I check for the length of the line being printed (to the file) and if the length exceeds 78 characters, I insert a newline to move to the next line.

Possible problems that I encounter or envisage I will encouter are:

1) Within functions etc, one normally indents the code, so also in if/for code blocks, so when Im processing a string of tokens that I know is ised for a function definition, after I move to a newline, i SHOULD also print out a tab to preserve the formatting

This is all I can think of at the moment and I am rather confused by all this. I thought it was an easy problem to begin with , but.....

Would appreciate if you comment on the misgivings of this possible solution as I have suggested here :D. Thanks


[edited by - hehenoobhehe on October 22, 2003 5:54:52 AM]
quote: Original post by XXX_Andrew_XXX
You might want to have a look at boost::spirit, from what I can remember it has some examples of how to parse C++ code in an Object-Oriented way, and then to attach actions to each rule.

If parsing is the job you need to do you might also look at flex and bison (lex and yacc). There should be plenty of freely available C++ language grammars which should be ready to use.


[edited by - XXX_Andrew_XXX on October 22, 2003 5:49:38 AM]



Problem is: I am NOT writing my own compiler or interpreter and this isnt a a school project that requires seraching for a C++ language grammar.

I''m doing something that is rather trivial as compaared to the above mentioned tasks: at best it could be called a code generator for a set of C++ classes that are concrete implementations for the interface that is declared in the header that is to be used (for code generation obviously) and since many many possible implementations of this interface are possible, I need some way to be able to generate the code without having to manually type(READ copy paste) stuff again and again.

So the possible solution was to use PERL to generate a skeleton implemenation file with placeholders/tags that can then be replaced by whatever is needed to get diff concrete classes.

Does this explain the problem a bit better?

This topic is closed to new replies.

Advertisement