Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Special Interest Groups
  3. C++ Gurus
  4. [Moved] Include files
Forum Updated to NodeBB v4.3 + New Features

[Moved] Include files

Scheduled Pinned Locked Moved C++ Gurus
4 Posts 4 Posters 3.5k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    cazador7907
    wrote on last edited by
    #1

    This is really just a simple question.

    As I write my programs in Qt, I've noticed that I'm duplicating include files from class to class (i.e. QDebug, QString, QVector, etc.). Does this have a negative affect on the program? It doesn't seem to me that it would. Or, is this just a matter of style?

    I've considered just dumping all of the most common includes (Vector, Debug, etc.) in a single header file and then just reference that. For the more "specialized" includes, I would just leave them in the classes where they're used.

    Laurence -

    1 Reply Last reply
    0
    • M Offline
      M Offline
      milot.shala
      wrote on last edited by
      #2

      As far as I know, a common practice is that you do only forward declaration in the header file and do actual includes on source file. By doing this you ensure that you gain shorter compilation time, because header files are compiled more often and source files not.

      1 Reply Last reply
      0
      • G Offline
        G Offline
        goetz
        wrote on last edited by
        #3

        I moved the thread to the C++ Gurus forum, since it's a general C++ topic, not specifically Qt related.

        If you only regard compiling as such, it is in practice irrelevant. While it is not allowed to define a class twice, this hardly ever happens. Every include file should have a so called "Include guard":http://en.wikipedia.org/wiki/Include_guard:

        @
        #ifndef FOO_BAR_H
        #define FOO_BAR_H
        class FooBar {
        //...
        };
        #endif
        @

        This way you can include the file as often as you want, but the actual contents are only included once (the first time you include the file). The naming conventions of the include guard vary.

        If you care about the speed your compiler works, it's better to avoid includes and replace them with forward declarations where possible (e.g. no use of a class in your own class - you would need to know the size of the class! Pointers and references are ok). This technique does NOT prevent from double includes!

        If you have a member of, say, type QString in your class:

        @
        protected:
        QString fooString;
        @

        you must #include <QString> in your header file. Otherwise you may get a syntax error. It could of course be that the QString was already included by some other include (e.g. from a QWidget base class); then it might work. But you cannot rely on other includes to do the work for you if you do not control them, so it is good practice to always include the stuff you use yourself. If for what ever reason QString is taken out of the other include your compilation will break.

        You can, of course, put some common and often used includes into a separate file. This could save you some maintenance work, but it does neither affect compilation time nor correctness of your code.

        http://www.catb.org/~esr/faqs/smart-questions.html

        1 Reply Last reply
        0
        • I Offline
          I Offline
          ivan
          wrote on last edited by
          #4

          For even faster (much) compilation, and some other nice side-effects (like binary compatibility for libraries) see the "d-ptr paradigm (Opaque pointer)":http://en.wikipedia.org/wiki/Opaque_pointer

          As far as the compilation speed goes - this way you can minimize the number of includes (a small speed boost) and you can change classes(1) without having chain reactions to recompile everything that uses them (big speed boost).

          --

          (1) naturally, doesn't apply to all changes

          Ivan Čukić | ivan.cukic(at)kde.org | KDE e.V.
          Qt Ambassador (from the old Nokia days)

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved