[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Add Include improvement

Continuing here from private discussion:

2010/7/21 Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx>
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:
1. 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

Current 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.

One possible 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?

Best regards,
-- Tomasz WesoÅowski