[ANSWERED] Include Files



  • Ok.

    I was working on a program this afternoon and noticed something odd. In the below example, GraphNode, Node and Edge all exist in the same folder in the project. However, for the GraphNode class to compile, I need to reference the full path to the Node and Edge classes.

    @
    #include <Graph/node.h>
    #include <Graph/edge.h>

    class GraphNode : public Node
    {
    ......
    }
    @

    Is this by design?



  • Are you using "Edge" in that class definition?


  • Moderators

    Whether or not you need to prepend the "Graph/" part to the include statement depends on the search path you set for your include files.

    You could also try to @#include "edge.h"@. That will check for the file in the local directory.



  • As Tobias stated check this link:

    http://msdn.microsoft.com/en-us/library/36k2cdd4.aspx

    Use
    #include "Graph/edge.h"



  • The two versions of include (<> and "") behave different. <> searches the include path and the behaviour of "" is compiler-dependent. But the directories searched by <> must be a subset of the directories searched by "".

    bq. Is this by design?

    So, yes, it is. My recommendation is to use <>, put the root directory of your sources into the include path and reference the files relative from this root.


  • Moderators

    Panke: The C/C++ standards do not specify the behavior of either #include <...> nor #include "...". Actually the included stuff is not even defined to be a file! The compiler is free to replace "#include <stdio>" with some piece of text that was compiled into it if it feels like doing so... There is no requirement of <> being a subset of "" in any standard. So much for the theory:-)

    In practice <> is a subset of "" in most compilers. In general <> searches paths build into the compiler or set up by the build system (gcc: -I/some/path or -isystem /some/path, other compilers may or may not use similar switches) plus some default system pathes (e.g. /usr/include in Linux). "" usually does search in the current source directory first before checking the system paths.



  • According to K&R 2nd edition, appendix A.12.4 File Inclusion, "..." is a (not necessarily strict) superset of <..>:

    bq. Similarly, a control line of the form # include "filename" searches first in association with the original source file (a deliberately implementation- dependent phrase), and if that search fails, then as in the first form[1]. The effect of using ', , or /* in the filename remains undefined, but > is permitted.

    fn1. the first form is #include <filename>

    [EDIT: fixed mistake, "..." is a superset, not a subset of <...>]



  • This code guru, so, my two pennies
    GCC compiler and it's smaller brother MingW which comes with my Qt Creator has this to say about the preprocessor directive #include:
    [quote]
    #include <file>
    This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the -I option (see Invocation).
    #include "file"
    This variant is used for header files of your own program. It searches for a file named file first in the directory containing the current file, then in the quote directories and then the same directories used for <file>. You can prepend directories to the list of quote directories with the -iquote option. [/quote]
    Therefore, in my case, using Qt Creator with MingW, all none standard headers will be referenced with "..." . A compiler may not necessarily follow the paths as outlined in MSDN, unless I explicitly instruct my compiler to do so. (I am too lazy to do that)



  • Good point, Taamalus.
    C++ standards are sometimes (very) far from our real life.
    The given environment determines the binding documentation, no matter how standards compliant it is.

    This problem is reflected in the acronym "RTFM":http://en.wikipedia.org/wiki/RTFM ;)



  • [quote author="Wolf P." date="1294651634"]Good point, Taamalus.
    C++ standards are sometimes (very) far from our real life.
    The given environment determines the binding documentation, no matter how standards compliant it is.

    This problem is reflected in the acronym "RTFM":http://en.wikipedia.org/wiki/RTFM ;)[/quote]
    So, I guess the correct answer to RTFM then, is to ask RWFM?

    (the "W" standing for "Which")



  • For Qt, /I/ havn't read it nor searched for it ;)
    But regarding my current main development environment, I have found that neither I nor my colleagues have read it early enough.

    When working with Qt Creator, you should consult one of the documentations of /MinGW/ or /Visua Studio/, depending on your software installation.



  • [quote author="Andre" date="1294653747"][quote author="Wolf P." date="1294651634"]This problem is reflected in the acronym "RTFM":http://en.wikipedia.org/wiki/RTFM ;)[/quote]
    So, I guess the correct answer to RTFM then, is to ask RWFM?

    (the "W" standing for "Which")

    [/quote]

    That of the compiler(s) you use. As far as I know the popular ones tend to behave quite similar on include paths.

    [EDIT: correct quotes]



  • There are two options, right?
    If there are online versions, can anybody post the appropriate links to GCC and MSVC?




  • Moderators

    Wolf P.: You only use two compilers? You are lucky then!

    Also note that the behavior of the compiler can change between versions (even though it should not change for fundamental things like include path handling:-).





  • If you have more, please add them to the "Learning/Links and Material":http://developer.qt.nokia.com/wiki/Category:Learning::LinksAndMaterial page of the wiki



  • [quote author="Tobias Hunger" date="1294679366"]Wolf P.: You only use two compilers? You are lucky then![/quote] How many compilers do you use?
    BTW: this sounds like a suggestion for one of our next polls ;)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.