C ++ #include标头

Question

there is a C++ book that says that we need to #include a header two times in two different files, one with a class, another with main() that uses the class from the previous file.

Here is the quote :

because our Sales_data class has a string member, Sales_data.h must #include the string header. Programs that use Sales_data also need to include the string header.

But there is something I don't understand. If we #include "Sales_data.h" in our main file, #include <(string)> is already in this header so no need to #include <(string)> in our main file.

From what I understand, when we #include a file in a main file, C++ only copy and paste the entirety of the file called with the header in the main file. So adding a second #include <(string)> is unnecessary. I'm talking about what happens when there isn't any #ifndef or #define in the header.

I did the test myself and I only needed to write #include <(string)> in one file and it worked. I isn't any # directive in either file except #pragma once in the header file.

Answer 1

The description you read is bogus. If the definition of a class C uses a type T, such as std::string , then that type needs to be available. Usually (except with Microsoft code) the header that defines C includes the header that defines T. Client code of C then needs only include the header that defines C.

The situation is different with more arbitrary indirect header inclusions. Let's say class C doesn't use std::string , but its header includes <string> . Then if your code that uses C, also uses std::string , it's good practice to let your code also include <string> . Even if that's not necessary at the current point of the code's evolution.

The case for client code including the necessary headers, as with at least former Microsoft style, is that it by itself can give faster builds (fewer file accesses during a build), and supports some build optimization via primitive tools such as Visual C++'s precompiled headers, where all headers to be precompiled need to be collected in one big Mother Of All Headers. The case against that practice is that it makes for more work in maintenance. And 80% of all programming is maintenance.

Answer 2

Consider the situation where Sales_data.h is modified to use a forward deceleration of std::string (instead of getting std::string 's deceleration from the system header.) This would allow Sales_data.c to compile with Sales_data.h , but would then cause compilation errors on any files including Sales_data.h , using std::string , but not including <string> .

You are correct in assuming that you may get this header indirectly from other header files, but it is not something you should rely on. I believe the author is suggesting it as a best practice.

Answer 3

This sentence

Programs that use Sales_data also need to include the string header.

can be interpreted (with a grain of salt) as pointing out that any program that uses Sales_data does include the string header, because it is included in the Sales_data header.

Of course a class should come with all required headers already included.

Answer 4

The problem with the statement is that there are 2 distinct cases which should be distinguished, but the statement lumps them together.

Case 1:

// Foo.h
#include <string>
class Foo {
  std::string member;
public:
  Foo() { member = "Hello, world"; }
};

Case 2:

// Foo.h
#include <string>
class Foo {
public:
  std::string Hi() const { return "Hello, world"; }
};

In the first case, the inclusion of <string> is an exposed implementation detail. The implementation could probably be changed to use a std::vector<char> instead. In the second case, std::string is part of the interface of class Foo , and no longer is an implementation detail.

In the second case, and only in the second case can you rely on <string> being included in "Foo.h" .