Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Good Job! #7

Open
asmwarrior opened this issue Jan 30, 2020 · 2 comments
Open

Good Job! #7

asmwarrior opened this issue Jan 30, 2020 · 2 comments

Comments

@asmwarrior
Copy link

I just want to say your project is great. I see this project is similar to Code::Blocks' internal CodeCompletion C/C++ parser, I hope those two can help each other in the future.

@JoshDreamland
Copy link
Owner

This means so much to me, especially coming from you. I'm a long-time fan of your work, actually. Thank you!

Repository owner deleted a comment from fundies Jan 31, 2020
@JoshDreamland
Copy link
Owner

Aaaand there it is. Anyway, ignore him.

I'm still in the middle of knocking some dust off of this project and getting support for the features from C++11 and 17 in. I have the latest C++20 draft in front of me, for that reason.

The biggest discrepancy between these two projects (Code::Blocks' parser and JDI) has to do with inspecting actual logic. The original JDI ignored actual function implementations completely. It passed right over them under the assumption that anything between { and } could not affect the set of definitions.

While that looks like an opportunity to allow Code::Blocks' to take over directly, unfortunately JDI doesn't get to be that lazy: I now need accurate evaluation of arbitrary logic in order to evaluate constexpr values, which can change how types are assigned to things entirely.

I have had the Code::Blocks (or general IDE) use case in mind for some time, now. It covers two of my three primary use cases for this project's design:

  1. ENIGMA's use case (cross-language C++ interop),
  2. Code completion use case (control-space in Code::Blocks)
  3. Cross reference and documentation generation (Doxygen, Doxyblocks)

There's definitely tons of overlap between the tools, but I don't know of a clean cut we can make between them, and the approaches look quite different. What do you have in mind?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants