To explain further, C++ conceptually has a three stage process to go from source to executable. The first is pre-processing (more or less all the lines beginning with #), then the compiler and finally the linker.
First, we must understand the difference between source files (typically .cpp) and header files (typically .h or .hpp). Source files are compiled, header files are not. The contents of header files may be compiled, as we shall see later. The selection of source files to be compiled is explicitly listed by the build tool, or computed by the build tool. For example, your IDE automatically selects all .cpp files to be compiled. Each source file is compiled by itself, independently of the others.
The first step is to pre-process each source file. This involves the pre-processor finding directives such as #include, #define and evaluating the contents of #if, #else etc. This is where header files come in - every #include directive is an instruction for the preprocessor to replace that line with the contents of the referenced file. That is, a header file will literally by copy/pasted into each source file that includes it. The output of the preprocessor is called a "translation unit".
Each translation unit is then compiled. The compiler does the ordinary work of ensuring you are following the syntax of C++, that you abide by its type system etc, and outputs a so-called "object file". Note that this terminology is unrelated to "object orientation", an object here means something akin to a function or global variable. Object files might end in a .o or .obj, depending on the tools you use.
Finally, the linker is the step that joins each of these translation units into an executable. Objects that are not defined in a given translation unit must be found in exactly one other translation unit, or the linker will give up because it cannot determine which one to use.
Using this information, we can understand what happened in this situation and the rules to prevent this re-occurring. What happened was that your IDE compiled three source files, learn.cpp, safestuff.cpp and SafeCracker.cpp. Because you #included the contents of SafeCracker.cpp into learn.cpp, there was two copies of the "SafeCracker" function emitted in the object files - one in learn.obj and the other in SafeCracker.obj.
When the linker went to make an executable from this, it found two objects for the "SafeCracker" function where there should only have been one. Thus, it issued a multiple defintion
fatal error LNK1169: one or more multiply defined symbols found
Another way to get this error would have been to have a second implementation of SafeCracker in another file.
SimonForsman's advice avoids this error by causing the SafeCracker function to be emitted only in SafeCracker.obj, but not in learn.obj. Thus, when the program is linked there are no duplicate symbols, there is one main() symbol and one SafeCracker symbol (ignoring the standard library ones), and everthing is correct.
One important lesson from the above is that #including a source file is always* the wrong thing to do! You will get multiple definitions if your source file has any definitions (which it should, otherwise it isn't doing anything). Likewise, header files should not contain definitions, because they are likely to be #included more than once and will again lead to multiple definitions.
Note that there is a final issue, but it is minor. Your header file should be completely enclosed by the include guard. Thus, your new SafeCracker.h file should look like this:
using namespace std;
string SafeCracker(int SafeID);
#endif // SAFESTUFF_H_INCLUDED
Note that you do not #include the "stdafx.h" in a header file.
* There are advanced techniques that (ab)use this, but for the moment pretend this is a hard rule