Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

CDT/Obsolete/C editor enhancements/Include management

< CDT‎ | Obsolete‎ | C editor enhancements
Revision as of 10:22, 30 April 2010 by Kosashi.gmail.com (Talk | contribs) (initial)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This is a problem page. Please treat it as a discussion page and feel free to insert your comments anywhere. My open questions are in bold--Kos 14:22, 30 April 2010 (UTC)

Problem

Description

The management of #include directives is probably one of the most repetitive tasks in C++ programming.

There's already an "Add include" feature, but it has its drawbacks: needs manual invocation by the programmer and is inaccurate in numerous situations. Clearly there's a lot of space for improvement.

Inspiration

JDT features wonderful include handling. If the Java include path is set correctly, then the programmer probably never has to add an import manually and is thus not distracted from actual coding.

The addition of new import can be done in two ways: when selecting a class from Context Assist which is not yet imported, or by invoking Organize Includes. JDT also warns about and allows to remove unused imports.

Solution proposal

A possible solution is to make CDT work like JDT. The problem gets a bit more complex in C++, though.

Invocation

A JDT-like solution would be to integrate adding includes with Context Assist.

Implementing a JDT-like solution would require little change to Context Assist behaviour. Context Assist, when invoked from a context with a part of name entered, would need to display a set of indexed symbols; ideally:

  • sorted in a clever way - how exactly?,
  • with the not-yet-included elements annotated in-place with the defining file).

A selection of not-yet-included option would invoke the include directive generation.

Generation

The generation of an #include directive also is not a trivial task, as it is in Java.

There are 2 decisions to be made:

1) How to include. This part is quite nicely handled by the Add include function, as it uses <header.h> if it can be reached by the project's include paths or "path/to/header.h" from current file if it can be reached by the file system. I believe it's the expected behaviour.

2) What to include. In case of classes, we might need either a simple declaration or a definition - the feature should decide which one is required. This problem can be illustrated by the scenario of "Add Include" feature stubbornly including iosfwd instead of expected iostream. (side note: This fact is confusing, as iosfwd only contains class forward declarations.)

As the guidelines say that headers should be light: Would it be acceptable by this feature to introduce a forward declaration of a class instead of including the full header to reduce compilation times, if we can show that a full declaration isn't needed in a given context?

Unused includes marking

Such feature could be implemented as a Codan checker.

This task may be more tricky to implement than in Java. To decide if a header is used, we'd also need to check symbols in a compilation unit against all headers included by it, recursively. Browsing a big hierarchy of headers against occurrences of a given symbol might be time-consuming on bigger projects.

Java has "flat" imports, so this problem doesn't exist there.

Do you believe that such feature is neccessary?

Folding

A little handy detail related to this problem would be to provide a possibility to fold a block of include directives.

Back to the top