Include Files Directory Structure

Discussion in 'C++' started by Mike Copeland, Jun 10, 2012.

  1. For years, I've been placing all my projects and all my various
    include files in a single directory (CPP). It's now quite large (and
    messy!), and I'm trying to convert my code to a newer compiler. This
    new system seems to expect each project's source to exist in a separate
    directory structure, but I want all projects share my include files.
    I can't figure how to structure my sources so that I can use a single
    #include "stdafx.h" statement in my project's main source file. A
    project's source stdafx.h file contains the following:
    ////////////////////////////////////////
    #include <stdio.h>
    #include <iostream>
    #include <sstream>
    #include <fstream>
    #include <sstream>
    #include <ostream>
    #include <string>
    #include <list>
    #include <vector>
    #include <map>
    #include <set>
    #include <bitset>
    #include <algorithm>
    #include <iomanip>
    #include <io.h>
    #include <stdlib.h>
    #include <string.h>
    #include <assert.h>
    #include <direct.h>
    #include <ctype.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <conio.h>

    #include "myclass3.h"
    #include "mylib2.h"
    #include "myua2.h"
    #include "myprint2.h"
    using namespace std;
    ///////////////////////////////////////////

    This works, but I'm trying to place my own include files
    ("myclass.h", etc.) in a different directory (/incl, for example) that
    can be referenced by many projects. I've tried various things, such as:
    #include "../incl/stdafx.h"
    in my main code, but that doesn't work at all (the compiler can't find
    the stdafx.h file).
    My structure (which doesn't work) is:
    /CPP
    /CPP/hello01 (a project directory)
    /CPP/incl (directory for all include files)
    /CPP/project02 {another project's directory)
    [etc.]

    I'm unable to find any examples (by googling) that demonstrate how to
    use a single "stdafx.h" file in sources other than the directory in
    which the source files reside (or how to set up a common "include"
    directory). It seems fundamental to multiple project development, but I
    just can't figure it out. Please advise. TIA
     
    Mike Copeland, Jun 10, 2012
    #1
    1. Advertising

  2. Mike Copeland

    Balog Pal Guest

    "Mike Copeland" <>
    > For years, I've been placing all my projects and all my various
    > include files in a single directory (CPP). It's now quite large (and
    > messy!), and I'm trying to convert my code to a newer compiler. This
    > new system seems to expect each project's source to exist in a separate
    > directory structure, but I want all projects share my include files.
    > I can't figure how to structure my sources so that I can use a single
    > #include "stdafx.h" statement in my project's main source file.


    Sounds unnatural.

    stdafx.h normally serves a single purpose: precompiled header. And is
    specific for the project. For the sad reason that this far MS refused to
    give us precompiled header that can bve shared between projects in a
    solution. (anyone who konws a way please tell.)

    So, having that the only good place of stdafx.h is the project's private dir
    for its includes (that may be its only dir that also has the .cpp files.)
    You can access includes for sharing from there either directly or via
    'include directories' option in the project.

    And certainly instead of writing #include "stdafx.h" in your sources you
    just make it include via the 'focred include' option, where you can spell
    $(projectdir)stdafx.h or something like that, independently of all the other
    dirs.

    > I'm unable to find any examples (by googling) that demonstrate how to
    > use a single "stdafx.h" file in sources other than the directory in
    > which the source files reside (or how to set up a common "include"
    > directory).


    What's there to demonstrate? You can use any include filenames residing
    anywhere at all. The .pch is NOT created form a header, but from the file
    you mark for 'Create' option -- that is normally stdafx.cpp if you use the
    defaults. Then you shall have the same includes in the other files in the
    same order up to #pragma headerstop (or all in the created thing.)

    So, for example you can name it stdafx_$(projectname).h and keep in that
    common directory.

    Though it IMO makes no sense whatsoever, common dirs are for common files,
    and those that are used by a single project better kept there.

    In your case I'd probably have two forced includes, one common and one
    project-specific, in that order.
     
    Balog Pal, Jun 10, 2012
    #2
    1. Advertising

  3. In article <jr32jj$2b02$>, says...
    > stdafx.h normally serves a single purpose: precompiled header. And is
    > specific for the project.
    > So, having that the only good place of stdafx.h is the project's private dir
    > for its includes (that may be its only dir that also has the .cpp files.)
    > You can access includes for sharing from there either directly or via
    > 'include directories' option in the project.
    > And certainly instead of writing #include "stdafx.h" in your sources you
    > just make it include via the 'focred include' option, where you can spell
    > $(projectdir)stdafx.h or something like that, independently of all the other
    > dirs.


    How do I do that? I don't understand this idiom. 8<{{
    >
    > > I'm unable to find any examples (by googling) that demonstrate how to
    > > use a single "stdafx.h" file in sources other than the directory in
    > > which the source files reside (or how to set up a common "include"
    > > directory).

    >
    > What's there to demonstrate? You can use any include filenames residing
    > anywhere at all. The .pch is NOT created form a header, but from the file
    > you mark for 'Create' option -- that is normally stdafx.cpp if you use the
    > defaults. Then you shall have the same includes in the other files in the
    > same order up to #pragma headerstop (or all in the created thing.)


    Well, I can't get that to work. <sigh> I tried to specify a specific
    directory (/incl) that has all my common include files, but the compiler
    "can't see" this location from where it's doing the project compile. I
    would have thought your statement here was so, but I cannot get the
    project stdafx.h include references to point to my /incl directory. 8
    <{{
    >
    > So, for example you can name it stdafx_$(projectname).h and keep in that
    > common directory.


    And how do I declare that specific name in my project's sources so
    the compiler actually sees that stdafx.h file? This seems to be where
    I'm having difficulty: the M$ file system references.

    > Though it IMO makes no sense whatsoever, common dirs are for common files,
    > and those that are used by a single project better kept there.


    Which what I'm trying to do. As I work on multiple projects, I don't
    want to have to manage multiple instances of my common library include
    files as I change any one of them. So, it makes sense that I keep the
    common files in one location, right?
    >
    > In your case I'd probably have two forced includes, one common and one
    > project-specific, in that order.
    >

    Isn't this the way most C/C++ programmers set their system up? Here
    I'm trying to (finally) do things "the right way", moreso than before.
     
    Mike Copeland, Jun 11, 2012
    #3
  4. Mike Copeland

    Balog Pal Guest

    "Mike Copeland" <>

    >> stdafx.h normally serves a single purpose: precompiled header. And is
    >> specific for the project.
    >> So, having that the only good place of stdafx.h is the project's
    >> private dir
    >> for its includes (that may be its only dir that also has the .cpp files.)
    >> You can access includes for sharing from there either directly or via
    >> 'include directories' option in the project.
    >> And certainly instead of writing #include "stdafx.h" in your sources
    >> you
    >> just make it include via the 'focred include' option, where you can spell
    >> $(projectdir)stdafx.h or something like that, independently of all the
    >> other
    >> dirs.

    >
    > How do I do that? I don't understand this idiom. 8<{{


    We're pretty much offtopic here, so please read the compiler options, most
    provide enough help on the GUI by just selecting it. And where you enter the
    option text, it shows available macros with their current value.

    >> > I'm unable to find any examples (by googling) that demonstrate how to
    >> > use a single "stdafx.h" file in sources other than the directory in
    >> > which the source files reside (or how to set up a common "include"
    >> > directory).

    >>
    >> What's there to demonstrate? You can use any include filenames residing
    >> anywhere at all. The .pch is NOT created form a header, but from the file
    >> you mark for 'Create' option -- that is normally stdafx.cpp if you use
    >> the
    >> defaults. Then you shall have the same includes in the other files in the
    >> same order up to #pragma headerstop (or all in the created thing.)

    >
    > Well, I can't get that to work. <sigh> I tried to specify a specific
    > directory (/incl) that has all my common include files, but the compiler
    > "can't see" this location from where it's doing the project compile. I
    > would have thought your statement here was so, but I cannot get the
    > project stdafx.h include references to point to my /incl directory. 8
    > <{{


    Well, everyone else can... If you actually tried setting the additinal
    include dir option, used up all internal diagnostics (/showincludes, most
    detailed build info, ...) and still no luck, try sysinternals' process
    monitor to see where the compiler attempts to open your files.

    >> So, for example you can name it stdafx_$(projectname).h and keep in that
    >> common directory.

    >
    > And how do I declare that specific name in my project's sources so
    > the compiler actually sees that stdafx.h file? This seems to be where
    > I'm having difficulty: the M$ file system references.


    You configure that in project options that are saved to .vcxproj. And used
    by msbuild that drives the compilation.

    In the solution explorer right click on the project -> properties -> a few
    hundred options...

    >
    >> Though it IMO makes no sense whatsoever, common dirs are for common
    >> files,
    >> and those that are used by a single project better kept there.

    >
    > Which what I'm trying to do. As I work on multiple projects, I don't
    > want to have to manage multiple instances of my common library include
    > files as I change any one of them. So, it makes sense that I keep the
    > common files in one location, right?


    Absolutely. :)

    >>
    >> In your case I'd probably have two forced includes, one common and one
    >> project-specific, in that order.
    >>

    > Isn't this the way most C/C++ programmers set their system up? Here
    > I'm trying to (finally) do things "the right way", moreso than before.


    Dunno what most people do :) Would guess most accept most of the defaults
    created by VS wizards. That hardcode the #include, hardcode the name
    stdafx.h. Probably okay as starting point.

    For big solutions better use common .props. But it's advanced stuff, after
    one mastered the basic options.
     
    Balog Pal, Jun 11, 2012
    #4
  5. Mike Copeland

    Ian Collins Guest

    On 06/11/12 12:20 PM, Mike Copeland wrote:
    > In article<jr32jj$2b02$>, says...
    >> stdafx.h normally serves a single purpose: precompiled header. And is
    >> specific for the project.
    >> So, having that the only good place of stdafx.h is the project's private dir
    >> for its includes (that may be its only dir that also has the .cpp files.)
    >> You can access includes for sharing from there either directly or via
    >> 'include directories' option in the project.
    >> And certainly instead of writing #include "stdafx.h" in your sources you
    >> just make it include via the 'focred include' option, where you can spell
    >> $(projectdir)stdafx.h or something like that, independently of all the other
    >> dirs.

    >
    > How do I do that? I don't understand this idiom. 8<{{


    You should ask on a windows programming group, this is all tool rather
    than language related.

    --
    Ian Collins
     
    Ian Collins, Jun 11, 2012
    #5
  6. Mike Copeland

    Krice Guest

    On 11 kesä, 03:20, (Mike Copeland) wrote:
    >    And how do I declare that specific name in my project's sources so
    > the compiler actually sees that stdafx.h file?


    Is there any reason to use precompiled headers? You know, you don't
    have to use them.
     
    Krice, Jun 11, 2012
    #6
  7. Mike Copeland <> wrote:
    > For years, I've been placing all my projects and all my various
    > include files in a single directory (CPP). It's now quite large (and
    > messy!), and I'm trying to convert my code to a newer compiler. This
    > new system seems to expect each project's source to exist in a separate
    > directory structure, but I want all projects share my include files.
    > I can't figure how to structure my sources so that I can use a single
    > #include "stdafx.h" statement in my project's main source file. A
    > project's source stdafx.h file contains the following:
    > ////////////////////////////////////////
    > #include <stdio.h>
    > #include <iostream>
    > #include <sstream>
    > #include <fstream>
    > #include <sstream>
    > #include <ostream>
    > #include <string>
    > #include <list>
    > #include <vector>
    > #include <map>
    > #include <set>
    > #include <bitset>
    > #include <algorithm>
    > #include <iomanip>
    > #include <io.h>
    > #include <stdlib.h>
    > #include <string.h>
    > #include <assert.h>
    > #include <direct.h>
    > #include <ctype.h>
    > #include <sys/types.h>
    > #include <sys/stat.h>
    > #include <conio.h>
    >
    > #include "myclass3.h"
    > #include "mylib2.h"
    > #include "myua2.h"
    > #include "myprint2.h"
    > using namespace std;
    > ///////////////////////////////////////////
    >
    > This works, but I'm trying to place my own include files
    > ("myclass.h", etc.) in a different directory (/incl, for example) that
    > can be referenced by many projects. I've tried various things, such as:
    > #include "../incl/stdafx.h"
    > in my main code, but that doesn't work at all (the compiler can't find
    > the stdafx.h file).
    > My structure (which doesn't work) is:
    > /CPP
    > /CPP/hello01 (a project directory)
    > /CPP/incl (directory for all include files)
    > /CPP/project02 {another project's directory)
    > [etc.]
    >
    > I'm unable to find any examples (by googling) that demonstrate how to
    > use a single "stdafx.h" file in sources other than the directory in
    > which the source files reside (or how to set up a common "include"
    > directory). It seems fundamental to multiple project development, but I
    > just can't figure it out. Please advise. TIA


    I would suggest that you factor out your common source code into a static
    library, that can be used by your other projects.
    (make a new VS project of type static library)

    Example:

    File structure:

    -- new static library
    libcommon/libcommon.h -- The main header of your New library
    libcommon/commonheader1.h
    libcommon/commonheader2.h
    libcommon/commonheader2.h
    ....
    libcommon/commonsource1.cpp
    libcommon/commonsource2.cpp
    libcommon/commonsource3.cpp
    ....

    -- project using static library
    project1/stdafx.h -- precompiled header if needed
    project1/header1.h
    project1/header2.h
    ....
    project1/source1.cpp
    project1/source2.cpp
    ....
    project1/stdafx.cpp

    Files:

    libcommon/libcommon.h
    ------------------------
    #include "commonheader1.h"
    #include "commonheader2.h"
    #include "commonheader3.h"
    ....
    ------------------------

    project1/stdafx.h
    ------------------------
    #include "../libcommon.h"
    ------------------------

    project1/source1.cpp
    ------------------------
    #include "stdafx.h"
    ------------------------
     
    Tobias Müller, Jun 12, 2012
    #7
  8. Mike Copeland

    Balog Pal Guest

    "Krice" <>

    >Is there any reason to use precompiled headers? You know, you don't
    >have to use them.


    Reducing compile time to 2-10% of the original looks like a pretty good
    reason to me.

    Also some win system includes (maybe even your own) use #import to include
    some COM component. That is incompatible with multiprocessor parallel build.
    But if you put those headers in the procompiled header, that problem is
    gone.
     
    Balog Pal, Jun 26, 2012
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. moon
    Replies:
    3
    Views:
    8,978
    Thomas Fritsch
    Sep 20, 2005
  2. Julien Phalip
    Replies:
    0
    Views:
    504
    Julien Phalip
    Feb 17, 2005
  3. john
    Replies:
    4
    Views:
    677
    Jim Higson
    Jun 15, 2006
  4. Andreas Bogenberger
    Replies:
    3
    Views:
    932
    Andreas Bogenberger
    Feb 22, 2008
  5. Henry Law
    Replies:
    3
    Views:
    960
    Henry Law
    Jul 22, 2004
Loading...

Share This Page