It's an installation / environment problem.
Symbols
Each time you compile a code, once the .cpp
has been compiled, the compilation unit is transformed into a object code (file with extension .o
). Your prueba.o
is passed to the linker, who finally generates an executable ( prueba.exe
). prueba.o
is finally eliminated, since it is an intermediate object. The linker is actually another different program, called ld
, which is used internally by gcc
so that you do not do the two steps manually.
From the linker's point of view, each global variable name, static variable or function name (whether external function or member function), of each object code , is called símbolo
.
What symbols does your executable have? Then all the functions of the class persona
, main
, all the symbols that are in the file <string>
, and all the symbols that are in the file <iostream>
, since they are all the files that you include in your program.
Well it turns out, that there is a symbol of the class std::string
(a std::string
is actually a typedef
of std::basic_string<char>
), which for some reason is not defined in the executable, but at the same time , it is called from the executable itself.
When trying to call this symbol (this method), it does not appear in the executable, hence it tells you that it can not be found. So something wrong is happening in the compilation / linking process, that the symbols are not "managing" well.
Name Mangling
Why does not the name of the problematic symbol in Christian come from the description of the error? Because, because C ++ has overload of functions and operators, in addition to spaces of names, and therefore, there can be functions and operations that are called equal, the compilers do something called name mangling
.
Fundamentally, it is giving each function / overload a unique name, since the linker "only understands C", where each name is unique (so to speak, that's why the quotes). The names are designed to avoid conflicts, and also each compiler and each platform performs a different name mangling (there is a great pollution of meaningless things, usually characters that indicate the type, and numbers that indicate the number of parameters or the length of each name). Knowing the problematic method in particular is impossible, unless you have the name demangler of your platform.
It is likely that when compiling, the compiler has given a name to a function or operator at the call point (that is, when you use it), which does not match the name generated for the function of the library.
My hypothesis is that you have not done an installation from scratch, and maybe you have installed the libraries from sources other than the compiler, or you have installed different versions unsuccessfully, or when you installed the compiler there were already certain libraries installed by other reasons, or you have done an update that has not been completed well, etc. Or there may be even precompiled versions of these libraries with the names already generated: there may be a compiled version of <string>
, with generated names different from those that the compiler generates at the point of call in your code; When there is an already compiled version, the compiler uses these and skips the processing of the line #include <string>
, resulting in the end that the treatment of names given to that precompiled version is different from the treatment of names given to your file. p>
In any case, either there are conflicts with the names, or simply, it is not compiled well and the member function does not even exist or has disappeared.
Conclusion
Your code is correct, and your compilation line is correct (I've compiled it on my own and executed correctly), so the problem is 100% environment-safe.
So you must reinstall everything, or better yet, work on a clean virtual machine and install and develop there. Windows things. Going to Linux to develop is also an option:).