main file: main.cpp

#include "file.h" #include <iostream> using namespace std; int main(int argc, char* argv[]){ func1(); return 0; };

header file: file.h

 void func1();

file.cpp file with file.h code

 #include <iostream> void func1(){ std::cout << "1"; };

so when you try to compile the code using the command (g ++ main.cpp), display a message that you don’t know what the func1 () function is, but when using (g ++ main.cpp file.cpp) everything works, so the doubt has crept in so compile, because if later in the files will be from 10 and all of them need to be registered after (g ++ main.cpp ...)? I use MinGW version gcc-6.3.0

  • one
    Do not worry. Gradually get to know what make is, how to combine files into libraries, etc., etc. ... - Harry

2 answers 2

That's right, if there are 10 files, then all 10 will have to be written on the compiler command line

 g++ file1.cpp file2.cpp ... file9.cpp main.cpp

Such a command line actually sequentially performs two stages of translation: first compiles the individual .cpp files into .o files, and then assembles the resulting .o files into the final program.

If you wish, you can use the -c option to separate these two steps: first compile .cpp files into .o files one by one

 g++ -c file1.cpp g++ -c file2.cpp ... g++ -c file9.cpp g++ -c main.cpp

and then complete the final build. However, for the final sbroki you still have to transfer all the received .o files in g++ (or in ld )

 g++ file1.o file2.o ... file9.o main.o

Those. no matter how you twist, there will still be some step where you have to list "many files" on the command line.

Libraries will help to get rid of too long file name enumerations, but in reality there is nothing terrible in such long command lines.

    Yes, g++ main.cpp file.cpp is correct.

    if later in the files will be from 10 and all of them need to be registered after (g ++ main.cpp ...)?

    Start using IDE, then you will not need to manually register anything.