One feature I plan to add to Add Include is an optional insertion of
fully qualified names instead of adding a using declaration. The new
behavior should become the default for header files.
I agree. Some users might also prefer to have the same behaviour in source files, so it should be settable in preferences.
Also, another improvement to make header files lighter could be to create a forwarding declaration of a class when it's enough, instead of adding the header? Could this be automated conveniently?
To make further progress in Add Include and include
analysis in general we need to be able to answer two key questions:
Given a source or a header file A that references a binding and the
header file B that defines it, determine if the header file B should be
included directly, or indirectly through some other header file C.
2. Given a source or a header file A and a header file B to be
included in A, determine if angle brackets or quotes should be used
implementation of Add Include tries to derive answers to these
questions from preexisting includes in the workspace. This approach has
several limitations, for small projects in particular.
There's another idea: if several candidates are found and there's no way to prefer one over another reliably, the editor could display a Context Assist-like box with some suggestions of headers. It would be best if it would somehow `learn` from the user's choices, but then remembering an include for each symbol isn't probably a good idea.
improvement is to allow user to specify a regular _expression_ filter that
prohibits direct inclusion of the header files that match it and
another filter that defines a set of files that should be included using
angle brackets. The filters should apply to the full file system path
of the include file and match an end part of it. CDT should come
preconfigured with filters for standard gcc includes.
Or the other way round- specify the set of filters which would specify ALL possible headers to include. This would probably default to the "public part" of standard libraries and all headers in workspace. Then the solution "traverse the include hierarchy bottom-up from the symbol declaration until you find an allowed header" could work neatly, I think - or would it also cause problems in some cases? Could it possibly replace the current approach? This needs some thought. Ideas?
Another thing is how to deal with additional libs on include paths- is it OK to expect from the user to specify explicitly the "public part" of any library which he adds to include paths?
I think it's acceptable, as the "allowed headers to automatically include" setting would be probably workspace-specific, not project-specific, so specifying each library once, not per-project, wouldn't be a big burden for the user imho.
Then, there's still the problem of < > vs " ".
Is the `voting` from preexisting includes a solution we want to stay with, or should we keep seeking a more reliable approach?
To be able to discover library include files that
haven't been included by the project yet, we can make indexer index all
header files along the include path.
I think this part is clear and could actually be done now- can we confirm?