Welcome to CodeCompletion redesign forum!

[rickg22]

This forum is for discussing the different C++ parser models, tokenizer, class browser, and everything related to revamping the Code Completion plugin.

It is *NOT* about reporting bugs in the current version.

Welcome!

[takeshimiya]

Great
I find the CodeCompletion plugin the most important plugin after the Compiler plugin.
Or more precisely, the parser inside the CodeCompletion plugin.

Once we'll have a complete AST generated of the code, we can do a lot of things: code completion, refactoring, code test coverage, graphic class diagrams, UML modeling, documentation on the fly in the tooltips, and any kind of thing involved with the code.

[Game_Ender]

Once we'll have a complete AST generated of the code, we can do a lot of things: code completion, refactoring, code test coverage, graphic class diagrams, UML modeling, documentation on the fly in the tooltips, and any kind of thing involved with the code.

All things that have been flying around in my head.  During my lunch tomorrow I am going to try and get Elsa working (only on linux first) and dive a little deeper its AST structure.  It is late now and I am off to bed, see you all tomorrow.

[Michael]

...I am going to try and get Elsa working (only on linux first)...

IMHO, it should be chosen a parser that compiles both in Windows and Linux and not just under one OS. I think this is important and should kept in mind since the beginning.

Michael

[TDragon]

Just to let everyone know that I'm still around, silently working on this stuff too. Actually, you can forget that I'm here. Maybe I'll surprise everyone one of these days...

IMHO, it should be chosen a parser that compiles both in Windows and Linux and not just under one OS. I think this is important and should kept in mind since the beginning.

While that would be easier, the possibility does exist for adapting Unix-centric code to our purpose -- especially if the Unix-centric code provides more overall functionality.

I'm currently working with the C++ grammar for ANTLR, which is surprisingly well done. Further updates as results warrant.

[grv575]

TDragon: since you've looked at the antlr c++ stuff as well, could you tell me why it requires a custom hash dictionary for the variable scopes?  All the other antlr grammers just provide a .g sytax file and a .g tree walker file.  (E.g. java - so I don't see why c++ would need extra code besides the .g files to work...)

[TDragon]

Mostly I think because it gave the author more control, but partially because C++ is contextual in so many ways that it was probably the best choice. Either way, it makes it easier for us to drop in yet another custom container if we need to

[Michael]

While that would be easier, the possibility does exist for adapting Unix-centric code to our purpose -- especially if the Unix-centric code provides more overall functionality.

Yes, that is ok . If the unix version provides more functionalities and could be adapted to Windows, then that could be a good choice.

Anyway, where I would like to put the accent is that it is important (to avoid problems/conflicts later) to chose from the beginning a parser that works or would work in both OSs.   

Michael