Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Regular expressions
Ceniza:
--- Quote from: stevenkaras on March 13, 2008, 09:48:36 pm ---Right now I think the best step forward would include the following:
...
3. have someone play with flex, come up with a good language spec for c++(worry about C later)
4. have someone else play with bison, and work on the C++ file for the parser.
--- End quote ---
3. Why flex? Besides, I already have the whole preprocessor's lexer working. The only symbols not yet generated (because they belong to another stage) are integer- and floating_point-literals. The preprocessor's lexer generates ppnumbers instead. Another missing part is string-literal concatenation (which will be done by the real lexer after it has retrieved preprocessed tokens).
4. I won't be up for that task. I already tried it with bison, and it was painful enough. If anyone feels like trying, please remember to use a code generation that plays nice with multi-threading (bison's default one doesn't).
For languages other than C and C++, flex and bison would be just fine. C and, even more, C++ are a PITA (Pain In The Ass, before someone asks) to parse by any means.
JGM:
--- Quote from: Ceniza on March 13, 2008, 10:50:40 pm --- PITA (Pain In The Ass, before someone asks)
--- End quote ---
Thanks for anticipating :lol:
JGM:
--- Quote from: stevenkaras on March 13, 2008, 09:48:36 pm ---Wow. I go away for a day or two and look what happens. This is really starting to come together as a team effort.
--- End quote ---
I like your attitude :)
--- Quote from: stevenkaras on March 13, 2008, 09:48:36 pm ---JGM> As for decoupling the language, the reason why you can't simply make the symbol table abstract is because languages are very different.
--- End quote ---
Yep, i will start having a really bad time, but then if theres is going to be a different parser for each language, I think would be good to standardize the parser structures, or create some abstract (interfaces) classes where others may derivate.
stevenkaras:
--- Quote from: JGM on March 14, 2008, 04:34:32 am ---Yep, i will start having a really bad time, but then if theres is going to be a different parser for each language, I think would be good to standardize the parser structures, or create some abstract (interfaces) classes where others may derivate.
--- End quote ---
True. Parsing in general is a PITA. My brain is fried from this week, but here goes:
1. Symbols from a language are placed into a symbol table.
2. The user requests a completion of the current symbol.
3. the C::C plugin determines the correct scope of the symbol(global, local, class)
4. Compare the current symbol against the proper scopes.
5. Provide a composite list to the user.
That kind of glazes over the general process, and I'm sure that eran can explain it in further detail. As for providing this functionality for multiple languages, it should be pretty easy. Figuring out how to generalize the symbol class should be a priority in order to achieve that. What we have should handle most languages, but it may need more tweaking.
Cenzina> Don't worry about it. I threw out flex as an option because it's more or less a standard. I also mentioned it because it may be easier to generate the lexer from a document specification, rather than a hard-coded version. Besides, we can always edit the code generated by yacc or bison or flex if it doesn't suit our needs.
JGM:
--- Quote from: stevenkaras on March 14, 2008, 06:07:11 pm ---1. Symbols from a language are placed into a symbol table.
2. The user requests a completion of the current symbol.
3. the C::C plugin determines the correct scope of the symbol(global, local, class)
4. Compare the current symbol against the proper scopes.
5. Provide a composite list to the user.
--- End quote ---
Also we need to know a detailed insight on how wxScintilla works for this purposes, if some one that has already worked with it could explain something :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version