Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Ceniza's CodeCompletion Project
Ceniza:
After setting all include dirs and defines from the GCC version I'm using in Linux, pptest05.cpp was preprocessed successfully. However, your test file gives me another problem here: /usr/include/bits/endian.h:4: #error "Never use <bits/endian.h> directly; include <endian.h> instead."
Too bad I don't have enough time to check into it :(
ollydbg:
Some suggestions:
Why not using " GCC -E" command to generate a "preprocessed file". After that, we can use our parser to read the output file.
See the example here:
http://www.network-theory.co.uk/docs/gccintro/gccintro_36.html
In my environment, I can use this command
gcc -E test.c -o test.i
Then we could take the parser on "test.i".
The "test.i" has very strict syntax like below:
# linenum filename flags
see the document here:
http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/cpp/Preprocessor-Output.html
ollydbg:
--- Quote ---include <endian.h> instead
--- End quote ---
But I don't want to change the standard header file supplied by mingw. endian.h was include in <iostream> :D.
Your code contains too many templates. It's a bit hard for me to read :D.
Jenna:
I just split this topic, because we went away from Ultimate++.
I did not find a better name, so you have to live with it, or suggest a better one :roll: .
Ceniza:
--- Quote from: ollydbg on February 16, 2009, 02:28:17 pm ---
--- Quote ---include <endian.h> instead
--- End quote ---
But I don't want to change the standard header file supplied by mingw. endian.h was include in <iostream> :D.
Your code contains too many templates. It's a bit hard for me to read :D.
--- End quote ---
The error message is reported because a name is not defined. It's a shame I did not consider to include some sort of tracking in the code for debugging purposes. That could be a next step. It could report, for example, include files in a "tree" view (something that lets you know what included what and where and the level of depth), when a define is added, when removed, when an #if/#ifdef/#ifndef is checked and satisfied, when it's ignored, and so on. I must admit that I was in a rush to finish that project, and now I lack the time to work on it again. Just to make it more evil and template abusive, the tracker could become another template parameter, with a no-op tracker as default.
I am really aware I abused templates and macros. Also, just like with any other project, I like to improvise and try to come up with different ways to do things. Since the project was originally conceived as a C++ parser, I also tried to make the project a test case. When I realized it would take way too long to make the parser, I reduced the project just to the preprocessor. I fixed many bugs on the way, but it looks like there are still some in there. Too bad the document that gives more insight on the project is in Spanish. Still, I tried to make the Doxygen documentation as complete as possible.
@Jens: Names are my strongest weakness. You can leave the topic name like that. Also, it was a good idea to split it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version