In C++ each file is compiled separately in what is called a "translation unit". Basically in most of the setups, a translation unit is compilation of a single .cpp file.
When the compiler compiles one .cpp file he doesn't see the information stored in other .cpp files. It only sees this single .cpp file.
The #include is a simple text replacement instruction. #include "add.h" tells the compiler to insert the content of the file add.h (found in compiler specific include search paths) just as-is into the file main.cpp.
When you write add(3, 4) the compiler needs to know about add. What does it return? Does it take unsigned long long arguments or unsigned char arguments? To tell compiler about a function return type and arguments type we use a function declaration, for example int add(int, int);. Or int add(int something, int anything);. The argument names in function declaration serve here as the documentation for the programmer - the important part for the compiler are types.
The compiler doesn't see the information stored in add.cpp. It is (typically) compiled as a separate translation unit. So we need to tell the compiler about the types around add() function. That information typically is stored in a header that is included in both translation units - in the "consumer" main.cpp that uses the function and in the "implementation" add.cpp that implements the function and what does it do. Typically the header is named the same as the file that implements the function(s) with a different extension.
why do we have #include "add.h" in file add.cpp?
Mostly as a defense for the programmer against errors and changes. Because two translation units are compiled separately, it's the programmer job to properly synchronize information between them.
If you would change in #include "add.h" ex. the return type of the function add, but forgot to change it in the implementation, the compiler would complain. Usage of the headers becomes more and more important when using classes, which define all the class members, inheritances etc. in one place in a header.
To "synchronize" the interface and the implementation for less errors, we include the header with the declaration in both the consumer and in the implementation. That way if you happen to change ex. the return type of the function, but forgot to change the add.cpp file, the compiler will complain.
I do not think it is necessary.
For such a simple project, it is not necessary, but I would consider it to be "bad style" or "spaghetti code" if you wouldn't do it. The add.h file tells me about what is in add.cpp file - what functions are defined them.
add.hdeclares a function only. The definition of this function inadd.cppwould work without the declaration as well. You're correct. But what if you have multiple functions which call each other? What if you have a class in.hwhich shall be defined in.cpp? A module (.cpp) with an interface (aka header,.h), that's the usual convention. (And, usually both with the same name - for convenience and readability.) ;-)addwas defined, but not declared (at least clang) when compilingadd.cpp.was defined, but not declared- how is that possible? Function definition is also a function declaration, from what I remember.