error i can't fix
Author
Ok, so I am somewhat new to C++ but I have known other languages such as Perl, Java, javascript, PASCAL and such for a long time. I bought a book with code snippets but they don't seem to be working. I get this error.
------ Build started: Project: Particle, Configuration: Debug Win32 ------
Linking...
WinMain.obj : error LNK2019: unresolved external symbol __imp__UnregisterClassA@8 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__DispatchMessageA@4 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__TranslateMessage@4 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__PeekMessageA@20 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__UpdateWindow@4 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__ShowWindow@8 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__CreateWindowExA@48 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__RegisterClassExA@4 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__LoadCursorA@8 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__LoadIconA@8 referenced in function _WinMain@16
WinMain.obj : error LNK2019: unresolved external symbol __imp__DefWindowProcA@16 referenced in function "long __stdcall WindowProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WindowProc@@YGJPAUHWND__@@IIJ@Z)
WinMain.obj : error LNK2019: unresolved external symbol __imp__PostQuitMessage@4 referenced in function "long __stdcall WindowProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WindowProc@@YGJPAUHWND__@@IIJ@Z)
.\Debug/Particle.exe : fatal error LNK1120: 12 unresolved externals
Build log was saved at "file://c:\Documents and Settings\Stretch\My Documents\My Code\C++\Examples\Particle\Debug\BuildLog.htm"
Particle - 13 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I have tried everything I can think of, but i can't fix a dang thing. Is their a setting I'm missing or something? I'm just not sure. Any help would be nice.
Not sure about this, but maybe you made the wrong choice about what type of project you were creating, such as a console application or windows application?
- Kevin
- Kevin
Author
Hey, that worked (the libraries). Now could you explain why that worked. Just interested and curious. Thanks for taking the time to help!
EDITTED FOR CLARITY
EDITTED FOR CLARITY
In your program, you made calls to several other functions. For these functions to be called from the compiled program, you need calling information: where, in memory, will the function be stored? This information is collected and processed during the linking step: all the function calls in your program are resolved by the linker, a program which looks in your program and in the libraries you include for the functions you call. When it doesn't find a function, it can't create the call to that function, so it aborts and tells you what it couldn't find.
In C and C++, you have three layers:
Compile-time: function declarations appear in header (*.h) files. These say what the functions are, what their parameters are. This is mainly used by the compiler to check that you don't do stupid things (such as passing a string to a function that expects an argument), but in some cases it also serves for compiling the call into machine code.
Here, you get C**** errors, when an undefined function is used.
Link-time: the linker then takes the list of called functions, and starts resolving them. It looks for information about those functions in (*.lib) library files and (*.o) object files. It complains if it doesn't find one, or (usually) if it finds one more than once (and thus doesn't know which to use). Using this information, the entire calling code for the executable can be compiled.
Here, you get LNK**** errors, when a symbol cannot be resolved.
Run-time: if you compiled using static linking, the linker also included the code it found in the library in your executable. The calls to library functions then work in the same way as calls to functions you created yourself. However, you can also use dynamic linking: instead of including the code of the function, the linker will include some code that looks in a dynamic library (.dll on windows, .so on unix/linux) for the code and puts it in memory when you execute the program. It still needs (.lib) library files to know how to write this "loading code".
Here, you get errors at execution stating that a .dll or .so could not be loaded.
In C and C++, you have three layers:
Compile-time: function declarations appear in header (*.h) files. These say what the functions are, what their parameters are. This is mainly used by the compiler to check that you don't do stupid things (such as passing a string to a function that expects an argument), but in some cases it also serves for compiling the call into machine code.
Here, you get C**** errors, when an undefined function is used.
Link-time: the linker then takes the list of called functions, and starts resolving them. It looks for information about those functions in (*.lib) library files and (*.o) object files. It complains if it doesn't find one, or (usually) if it finds one more than once (and thus doesn't know which to use). Using this information, the entire calling code for the executable can be compiled.
Here, you get LNK**** errors, when a symbol cannot be resolved.
Run-time: if you compiled using static linking, the linker also included the code it found in the library in your executable. The calls to library functions then work in the same way as calls to functions you created yourself. However, you can also use dynamic linking: instead of including the code of the function, the linker will include some code that looks in a dynamic library (.dll on windows, .so on unix/linux) for the code and puts it in memory when you execute the program. It still needs (.lib) library files to know how to write this "loading code".
Here, you get errors at execution stating that a .dll or .so could not be loaded.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
