On Wed, Jul 21, 2010 at 12:32 PM, Tomasz Wesołowski
<kosashi@xxxxxxxxx> wrote:
Inserting forward declaration is different from adding an include and should be kept separate in my opinion. For an unresolved symbol there could be two quick fixes, one to add include and another one to add a forward declaration.
While we're at it, note that the "Add Include" action already does two things: adds the include AND adds the using declaration. That's understandable.
You suggested that you'd want the action to add either the `using` declaration or a qualified name upon calling "add include", depending on the context (header / source). My suggestion is analogous behaviour for #include: full include in source and minimal include in header (which translates to "only a forwarding declaration if it's sufficient"). Could be preference-dependant.
When "Add Include" is accurate enough, I'd want this behaviour to be triggered automatically upon Context Assist hit, to the extent settable in preferences (
319175,
wiki 1,
wiki 2).
To sum up, a clear solution would be to:
a) have 4 accessible routines prepared:
--- add include for name
--- add forwarding declaration for name
--- add namespace using declaration for name
--- change name into qualified name to resolve namespace
b) have "Add Include" action and Context Assist selection trigger a subset of the above, depending on the context and preferences.
Agree.
It would be very annoying if Add Include on vector proposed stl_vector.h together with vector. CDT should be smart enough to never propose header files not intended for direct inclusion.
I agree, that's the ideal situation. But this idea was that IF we cannot reliably find a good header in a given context, it's probably better to give the choice than take the first include.
Of course "just making Add Include work properly" is the main goal and the above won't be necessary if we achieve it.
A filter for headers prohibited for direct inclusion is likely to be simpler.
I'd disagree here.
Consider a situation: The user starts to use a new library in the project.
>From the documentation, they exactly know what headers they are going to use.
OTOH, they probably know nothing on internal headers of the library - why would they?
Consider some libs:
- Python: clients usually need to only include "Python.h". However, the include folder is cluttered by dozens of intermediate headers not meant for including. There are loads of other single-header libraries, take Open Dynamics Engine for example.
- QT: Headers of the form <QSomething> (and probably <QtSomething>, I don't have QT here, just browsing samples) seem to be API, so it'd be easy to indicate them with a simple pattern.
In both cases, selection of "allowed" headers is easy because the user knows what parts of API he expects to have proposed, while selection of "disallowed" headers would require some knowledge of the `insides` of a library. I believe "what API headers I need?" is easier to answer than "what non-API headers lurk somewhere in my include paths?".
Then, consider defaults for standard libraries. The set of standard ISO C and C++ headers is well-known. The non-standard headers could be added manually by the user.
OTOH, the set of disallowed headers of STL is a) much more complex and b) probably compiler-dependant (the standard doesn't dictate the implementation, right?).
Therefore, I think it's quite reasonable and more intuitive to go for "allowed headers" rather than "disallowed headers".
Simple libraries are likely not to have any filters at all. In some cases few header files inside the project itself should be banned from direct inclusion It looks like both, positive and negative, filters have their merits. We can have a list of (directory matcher, positive filter, negative filter) tuples. The filters should use globs like most other filters in Eclipse . By default the positive filter is *, the negative filter is empty. The filters for the MinGW gcc library may look like:
Directory matcher Positive Negative
MinGW/include/c++/* * *.h
MinGW/include/c++/*/ext * *.h
MinGW/include/* *
MinGW/lib/gcc/mingw32/*/include *
I used wildcards in directory matchers to make sure that the filters don't depend on the version of MinGW.
Then, there's still the problem of < > vs " ".
For that, would it be OK to assume <foo> if in include paths and "foo" otherwise?
Unfortunately this is not always true. In the code base I'm working with, gcc headers are included with <> and everything else, including other libraries in the include path, with "".
The voting approach doesn't work very well, does it?
So if we come up with something more reliable, we have a green light to remove the old approach and replace it with new one altogether?
BTW- I believe that this functionality should be not only reliable but quick. I sincerely hope that getting include hierarchy is quick enough not to slow down the process.
We should try to preserve the learning behavior to a degree it doesn't contradict explicitly provided filters. It may be useful for libraries, for which the filters are not configured.
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?
I don't see why not.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
