0

I am building a simple C++ program, which consists of a main function and two nested classes. In each class and function I use strings and vectors - thus the software requires additional libraries.

Each class is defined in a separate myClass.h file, and the corresponding myClass.cpp.

My problem concerns additional libraries. Suppose I use the #include <string> in main.cpp. How can I pass that library to myClass.h and myClass.cpp?

Paul Roub
  • 36,322
  • 27
  • 84
  • 93
Fra_24
  • 113
  • 4
  • 1
    Possible duplicate of [Problems importing libraries to my c++ project, how to fix this?](http://stackoverflow.com/questions/24715864/problems-importing-libraries-to-my-c-project-how-to-fix-this). – πάντα ῥεῖ Sep 01 '15 at 18:13

2 Answers2

3

If your software is simple enough (e.g. a few translation units, and less than ten thousand lines of source code), you'll better have a single header file e.g. myproject.h for all your project, and #include that file everywhere. Then, that myproject.h header could also #include external headers (perhaps the <vector> and <string> from the standard C++ library) for outside libraries.

There is no requirement in C++ to have one header file (or one translation unit) per class, and I believe there is not always a good reason for that (but some other persons think differently). You can put several related classes in the same translation unit, and you can have many declarations in a single header file.

But all this is a matter of opinion, convention and of coding styles. For some simple project it does not matter that much, as long as you stay coherent. My opinion is that having several thousand lines of code in a single source (or header) file is not an issue, and I usually code that way. I strongly dislike having (like sort-of required in Java) one class per source file, because I hate having hundreds of tiny files (of less than a hundred lines each). BTW, the C++ compiler might take a longer time to compile your project with such a one-class-per-file approach (because C++ container standard headers like <map> or <vector> are pulling a lot of included code: on my GCC 5 GNU Linux system #include <vector> is expanded to more than ten thousand lines, or about 340Kbytes).

Notice also that organization of classes (and declarations) inside source files is much less an issue than the overall design of your class hierarchy. For example, if you start with a single myproject.h approach (like I am suggesting) and later become unsatisfied with it, spreading your classes in several headers would be quite easy (an hour of copy/pasting and some few #include-s to add); but redesigning your classes and their inheritance or signatures, that is refactoring your code, is significantly more difficult.

Study the source code (e.g. on http://github.com/ ...) of several C++ free software (e.g. fish-shell, POCO, cpp-netlib, jsoncpp and many others) to forge your own opinion.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
1

You don't "pass" libraries. Each source file that needs to use a library should #include that library's header file(s). If it's only the body of the code that uses the library, put the #include in the .cpp file. Only add it to the .h file if you need to - for example if a class from the included library is used as a parameter to a function declared in that .h file.

There should be no need to #include the same library into both the .h file and the corresponding .cpp file. Do one or the other.

Simon B
  • 232
  • 6
  • 14