10

I'm a bit confused at the moment because I'm planning to include multiple source and header files for the first time in one of my projects.
So I'm wondering if this would be the right approach?
Do I have to include the string header in every source file that uses it directly?
And what about the "stdafx.hpp" header that Visual C++ wants me to include?

Would that be the way to go?

main.cpp

#include "stdafx.hpp"
#include <string> //?
#include <stringLib1.h>
#include <stringLib2.h>
using std::string;

//use a windows.h function here
//use a stringLib1 function here
//use a stringLib2 function here

stringLib1.h

#include "stdafx.hpp"
#include <string>
using std::string;

class uselessClass1
{
public:
    string GetStringBack1(string myString);
};

stringLib1.cpp

#include "stdafx.hpp"

string uselessClass1::GetStringBack1(string myString) {
    return myString;
}

stringLib2.h

#include "stdafx.hpp"
#include <string>
using std::string;

class uselessClass2
{
public:
    string GetStringBack2(string myString);
};

stringLib2.cpp

#include "stdafx.hpp"

string uselessClass2::GetStringBack2(string myString) {
    return myString;
}
Forivin
  • 14,780
  • 27
  • 106
  • 199
  • 7
    Yes you have to include the header files in every file you want to use it. However you should not use the `using` keyword in a header. This is not good style. – code monkey Sep 16 '14 at 14:07
  • @user2572585 Who gives about style? – nbro Sep 16 '14 at 14:08
  • 2
    @cell I hope that was a sarcastic comment and you weren't serious. – Cory Kramer Sep 16 '14 at 14:08
  • @Cyber It's not a matter of style. And I was serious. – nbro Sep 16 '14 at 14:09
  • 3
    In every c file you include your header, the `using` will be included too. That can produce some bad naming conflicts. – code monkey Sep 16 '14 at 14:10
  • @user2572585 That's more like it ;) – nbro Sep 16 '14 at 14:11
  • 2
    Adding `using` statements to header files is one of the fastest ways to cause [namespace pollution](http://stackoverflow.com/questions/8862665/what-does-it-mean-global-namespace-would-be-polluted) – Cory Kramer Sep 16 '14 at 14:11
  • 1
    @Cyber Which is not a matter of style. – nbro Sep 16 '14 at 14:11
  • You should put your code in a `namespace`. Then it is okay to have a `using` inside your `namespace` in your headers. You should ***never*** use `using` in the global `namespace` of a header. – Galik Sep 16 '14 at 14:16

4 Answers4

7
  1. A good practice is usually to include only what your code uses in every file. That reduces dependencies on other headers and, on large projects, reduce compilation times (and also helps finding out what depends on what)

  2. Use include guards in your header files

  3. Don't import everything by polluting the global namespace, e.g.

    using namespace std;
    

    but rather qualify what you intend to use when you need it

  4. You don't need stdafx.h in your project unless you're using precompiled headers. You can control this behavior in the VS project properties (C/C++ -> Precompiled Headers -> Precompiled Header)

Community
  • 1
  • 1
Marco A.
  • 43,032
  • 26
  • 132
  • 246
3

The stdafx.h header is needed if precompiled header is enabled in VS. (Read this one) You only need to include the stdafx.h in your .cpp files as the first include.

Regarding the header and cpp files (which come in pairs), include things necessary for the declaration in the header, and include everything else (necessary for the definition) in the cpp. Also include the corresponding header in its cpp pair too. And use include guards.

myclass.h

#ifndef MYCLASS_H  // This is the include guard macro
#define MYCLASS_H

#include <string>
using namespace std;

class MyClass {
    private:
      string myString;
    public:
    MyClass(string s) {myString = s;}
    string getString(void) {return myString;}
    void generate();
}

myclass.cpp

#include <stdafx.h>  // VS: Precompiled Header
// Include the header pair
#include "myclass.h" // With this one <string> gets included too
// Other stuff used internally
#include <vector>
#include <iostream>

void MyClass::generate() {
    vector<string> myRandomStrings;
    ...
    cout << "Done\n";
}

#endif

Then in main(...), you can just include myclass.h and call generate() function.

Community
  • 1
  • 1
Gyebro
  • 1,511
  • 13
  • 19
0

The stdafx include should be at the top of every .cpp file and it should NOT be in .h files. You could put #include < string > in stdafx.h if you don't want to put it in every other file.

XTF
  • 1,091
  • 1
  • 13
  • 31
  • You *can* rely on stdafx to give you common headers and certainly a lot of developers do, but I wish they wouldn't (and I wish there was a VS switch to consider this an error). The problem is that it makes it difficult to reuse files between different projects since each will have a different stdafx. – dlf Sep 16 '14 at 14:26
  • True, but you can easily add the missing headers when you encounter the error can't you? – XTF Sep 16 '14 at 19:49
  • Yes, but if it's another person in a different department working on a different project that happens to share code with yours who makes the discovery, the situation becomes political! :) – dlf Sep 16 '14 at 19:51
-1

I suppose that you must be having your own header files also which might be requiring in other cpp files and header files. Like the one you gave

#include <stringLib1.h>
#include <stringLib2.h>

In my opinion, its better to create one common header file in which you include all the common library header files and your project header file. This file then you can include in all the other cpp files and header file. And it will be better to use header guards also.

So, considering a common header file "includes.h".

#ifndef INCLUDES_H
#define INCLUDES_H

#include <string>

#include <stringLib1.h>
#include <stringLib2.h>

/***Header files***/    

#endif  //INCLUDES_H

This is now your common header file. This you can include in all your project files.

Arpit
  • 767
  • 7
  • 20
  • 3
    What a dreadful idea. Unless you're precompiling this header, why on earth would you needlessly include all headers in every translation unit?! – Lightness Races in Orbit Sep 16 '14 at 14:19
  • I suppose you've never worked on a large C++ project.. this idea soon proves to be hell on Earth – Marco A. Sep 16 '14 at 14:45
  • 1
    As a matter of fact, in my company this approach is followed. And since you guys have pointed out that this is not a good approach, I will look into it further more. Thanks. – Arpit Sep 16 '14 at 15:00