C++ Dois-je inclure des bibliothèques standard pour chaque fichier source?

Je suis un peu confus pour le moment parce que j'ai l'intention d'inclure plusieurs source et les fichiers d'en-tête pour la première fois dans un de mes projets.

Alors je me demandais si ce serait la bonne solution?

Dois-je inclure la chaîne d'en-tête de chaque fichier source qui utilise directement?

Et que dire de la "stdafx.hpp" en-tête que Visual C++ veut de moi?

Serait-ce la voie à suivre?

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;
}

Oui, vous devez inclure les fichiers d'en-tête de chaque fichier que vous souhaitez utiliser. Cependant, vous ne devez pas utiliser le using mot-clé dans un en-tête. Ce n'est pas un bon style.
J'espère que c'était un commentaire sarcastique, et vous n'avez pas grave.
Dans chaque fichier c vous d'inclure votre en-tête, le using sera aussi inclus. Que peuvent produire certaines mauvaises conflits de noms.
L'ajout de using déclarations de fichiers d'en-tête est l'un des moyens les plus rapides pour cause espace de noms de la pollution de l'
Ce qui n'est pas une question de style.

OriginalL'auteur Forivin | 2014-09-16

c++header-files include precompiled-headers standard-library

4
1. Une bonne pratique est généralement d'inclure seulement ce que votre code utilise dans chaque fichier. Qui réduit les dépendances sur d'autres en-têtes et des, grands projets, de réduire les temps de compilation (et aussi aide à trouver ce qui dépend quoi)
2. Utilisation inclure des gardes dans vos fichiers d'en-tête
3. De ne pas importer le tout par polluantes l'espace de noms global, par exemple
```
using namespace std;
```
  mais plutôt à qualifier ce que vous avez l'intention d'utiliser quand vous en avez besoin
4. Vous n'avez pas besoin stdafx.h dans votre projet sauf si vous êtes en utilisant les en-têtes précompilés. Vous pouvez contrôler ce comportement dans le VS propriétés du projet (C/C++ -> Headers Précompilés -> en-Tête Précompilé)
OriginalL'auteur Marco A.

La stdafx.h en-tête est nécessaire si un en-tête précompilé est activé dans le VS. (Lire celui-ci)
Vous avez seulement besoin d'inclure les stdafx.h dans votre .cpp fichiers comme la première inclure.

Concernant l'en-tête et les fichiers cpp (qui vont par paires), inclure des choses nécessaires pour la déclaration dans l'en-tête, et tout le reste (nécessaire pour la définition) dans le rpc. Également inclure l'en-tête correspondant à son rpc paire de trop. Et l'utilisation inclure des gardes.

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

Puis dans main(...), vous pouvez simplement inclure myclass.h et appel generate() fonction.

OriginalL'auteur Gyebro

0

La stdafx inclure devrait être la priorité de tous .fichier cpp et il ne devrait PAS être dans .h fichiers.
Vous pourriez mettre #include < string > dans stdafx.h si vous ne voulez pas mettre dans tous les autres fichiers.

Vous s'appuyer sur stdafx pour vous donner des communes les en-têtes et certainement beaucoup de développeurs de faire, mais je souhaite qu'ils ne serait pas (et je souhaite qu'il y ait un VS commutateur de considérer cela comme une erreur). Le problème est qu'il rend difficile la réutilisation des fichiers entre les différents projets, car chaque projet est différent stdafx.
Vrai, mais vous pouvez facilement ajouter des en-têtes manquantes lorsque vous rencontrez l'erreur ne pouvez-vous pas?
Oui, mais si c'est une autre personne dans un autre département de travail sur un autre projet qui arrive à partager le code avec le vôtre, qui fait la découverte, la situation devient de politique! 🙂

OriginalL'auteur XTF
-1

Je suppose que vous devez avoir vos propres fichiers d'en-tête qui peut être exigeant dans d'autres rpc fichiers et les fichiers d'en-tête. Comme celui qui vous a donné
```
#include <stringLib1.h>
#include <stringLib2.h>
```
À mon avis, de son mieux pour créer un en-tête commun de fichier dans lequel vous incluez toutes les communes de la bibliothèque de fichiers d'en-tête et de votre projet fichier d'en-tête. Ce fichier alors que vous pouvez inclure dans tous les autres fichiers cpp et le fichier d'en-tête. Et il sera préférable d'utiliser l'en-tête des gardes aussi.

Donc, compte tenu d'un en-tête commun de fichiers ".h".
```
#ifndef INCLUDES_H
#define INCLUDES_H

#include <string>

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

/***Header files***/    

#endif  //INCLUDES_H
```
C'est maintenant votre commune de fichier d'en-tête. Ce que vous pouvez inclure dans tous les fichiers de votre projet.

Quel horrible idée. Sauf si vous êtes à la précompilation de cet en-tête, pourquoi sur terre serait vous inutilement inclure tous les en-têtes dans chaque unité de traduction?!
Je suppose que vous n'avez jamais travaillé sur un gros projet C++.. cette idée bientôt s'avère être l'enfer sur Terre
Comme une question de fait, dans mon entreprise, cette approche est suivie. Et, puisque vous avez souligné que ce n'est pas une bonne approche, je vais regarder de plus en plus. Merci.

OriginalL'auteur Arpit

Vous devez vous connecter pour publier un commentaire.