Why must we reference projects, for C++, in Visual Studio 2013 when we intend to use a method from a referenced project? I'm confused because we use the #include preprocessor directive, which is copying & pasting the code we intend to use into the same header file which is still above/before the method that is actually using it.
Basically, even if I have all the projects in the same solution file, and the header files are correctly finding each other (intellisense doesn't complain/ proper linting occurs), I still get linker errors. But even if referencing projects is purely about resolving linker errors, if intellisense can peek/show definition to the code I am importing from a separate project, doesn't that mean Visual Studio also knows which project I'm linking against?
There must be a reason why, we both #include and reference the included projects even now in VS 2013. Could someone help explain why?
"There must be a reason why, we both #include and reference the included projects even now in VS 2013. Could someone help explain why?"
Including header files allows to use the declarations (of functions, classes or structs) from there. But to get a completely executable program there's more necessary:
The compiler needs to know where to get the #include'd header files from
The compiled source code from a different project needs to be linked to the final artifact
The linker needs to know where to get the linked libraries from
If you have header only libraries, the least 2 points won't be relevant, but Visual Studio would still need the project reference for resolving the header file pathes.
For Visual Studio in particular there's also the #import directive available, that makes it easier to link against shared libraries (and keep those as standalone projects, instaead of referenced ones from the same solution).
No, it is computationally infeasible for a linker to magically guess which definitions you want to link into your project at any given time. It's a good thing that it does not attempt to do so.
The C/C++ compiling process has two steps:
compile (.c/.cpp) source code into a lib (requires external .h files)
link all necessary lib files into an executable (requires both the own compiled lib files and external lib files. After all, the external .h file only contains the definition)
Related
I have a problem and I can't fix it no matter what I do. Basically my university is using Stanford libraries for c++ and the only program that can use those libraries out of the bag is vs2008.
I'd prefer to use VSCode, but I can't seem to get it to work. There is a folder with .h files and a compiled .lib file. The header files have nothing in them except for function names. Thing is that vs code can find those header files and recognizes functions but can't compile any of it. I guess it can't link to .lib file. How can I fix this? I did everything I knew but nothing worked.
We have an excellent MFC/C++ project that handles the data to and from a legacy database. All classes are exported with AFX_EXT_CLASS (which is dllexport if i am not misunderstanding it). I am currently writing a wrapper so that we can use it in C# applications. This is my first real wrapper, so please bear with me.
This is what i have done:
Compiled the project with /Yc /Gm- /Clr. It produces a .lib and a .dll.
I have access to the source so, i added the path of the header files in my C++/Cli project. It therefore recognises the types.
I added the .lib to the linker input in the C++/Cli project.
I have added the .dll as a reference in the C++/Cli project.
In the C++/Cli project, i have a stdafx.h that looks like the stdafx.h in the native project.
If i understand this correctly, the .lib is the implementation, the .dll is the "wrapper" to be able to reference it as a .net-dll, and the header files are the class definition.
Now, i can define native objects in the C++/Cli project, but when i access functions therein and try to build it, it throws external reference not found errors on the objects that i am trying to define.
This is understandable because it can not know that the header files point to the implementation in the .lib. The header files are used as is.
What am i doing wrong? Am i supposed to point at the header files? Should it not use the .dll to find the class definitions that are implemented in the .lib file? Should i create a .def file to point at the library?
There seem to be a missing piece to this puzzle and i am expecting to experience an aha-moment any moment now...
Please note that this is not a general linkage question, it is specifically about the practical use of AFX_EXT_CLASS exported classes, MFC and C++/CLI.
Cheers and thank you
You don't need your step 4. Also, try to don't use Precompiled headers like stdafx.h in your project, Go to C/C++ -> Precompiled Headers -> Not using precompiled headers and Check Linker -> Additional Dependecies -> Inherit from parent or project defaults. Finally, check the error message link if it's point to windows library use missing try to include .lib library using #pragma comment (lib, "yourlib.lib")
I can't find any text reference to libboost_random-vc140-mt-1_61.lib in any project file or source file, yet Visual Studio 2015 really seems to need it. If I rename another static library libboost_random-vc140-mt-1_61.lib, the linker completes(not pulling any symbols from the bogus boost library). I had used b2.exe at some point in the past to generate such a file, but recently have mounted a Visual Studio project for boost system and random, where the static library outputs have different names. Where are these old references coming from?
Since you're on Windows, this is likely to be the result of the auto-linking functionality of Boost.
More details are in boost/config/auto_link.hpp.
You can disable this by defining BOOST_ALL_NO_LIB.
This question already has answers here:
C++ static variable in .lib does not initialize
(2 answers)
Closed 4 years ago.
I have some legacy C++ code which I wan't to move to a (static) library (.lib).
However, the legacy C++ code uses constructors of global objects to do some initialization (pls don't discuss that this may be bad practice - it basically works and it its legacy code I don't want to change). This works as long as the global object becomes part of the .exe, which always happens if the source code and hence its .obj file, containing that global object, is part of the .exe project in visual studio (2008). If I move the module to the library, the linker will not include this module, since it is not referenced by any module of the .exe. So I need to enforce linking that module into the .exe
I know the linker cmd line option /INCLUDE, which I can also specify using #pragma comment(linker, "/iclude: ... "). However, there are some problems:
I need to specify the decorated name of the C++ object. I can work around this by some dummy extern "C" symbol such as an int, still not nice and there are a lot of them.
I either have to specify all symbols in the linker commandline (as I mentioned, there are a lot of them) or, if I use #pragma, the #pragma statement has to be part of some module of the .exe (or included as headerfile by such a module). It did not work to place the #pragma into the source code where the symbol is defined (in the library). So both ways enforce linking the symbols by the build process of the .exe (either by commandline or by sourcecode of the .exe) but not by the code of the library.
So what I'm looking for is a way in visual studio 2008 to enforce linking a module by definition of the module of the library like: "if library X.lib is specified as input of the linker, then module Y.obj of X.lib will always be linked into the .exe, regardless any references by other modules". Preferably not using decorated names.
So I'm going to answer my own question. In fact it is another workaround.
The workaround is not a linker option but a VS setting, that only works if both, the .lib and the .exe are in the same solution and if the dependency of the .exe to the .lib is correctly sepcified in the solution settings.
In the "Linker Property Page" of the VS project of the .exe set "Use Library Dependency Inputs" to "Yes" so the .obj(s) of the .lib will be used instead the .lib as linker input. Since the linker includes all .obj(s) specified as input, whether referenced or not, the effect is similar to specifying all source modules of the .lib as part of the .exe project itself.
http://msdn.microsoft.com/en-us/library/024awkd1%28v=vs.90%29.aspx
One drawback is, that this setting is not .lib specific. It affects all dependent .libs in the solution (but not the libs specified as additional input). Check the linker commandline to know the effect.
I'm building a socket program in Visual Studio 2003 .NET
I #include <winsock2.h> header file but also noticed that I had to link in the WS2_32.lib to fix the unresolved winsock function errors.
In other homework projects, I just added a header file and used it's functions - without adding the corresponding library.
How is this so?
Are some standard header file libraries already pre-linked in Visual Studio or something else?
Thank You!
The socket functions are actually implemented in ws2_32.dll. In order for the linker to be able to find them, you need to add the ws2_32.lib import library to your project. Note that the import library does not contain the actual code for the functions, but only information about where to find the actual functions (in ws2_32.dll).
You don't mention which other header files you're referring to, but if it's something like <string.h> then that is already in the MSVC runtime library; if it's something like <windows.h> then those functions are provided by import libraries such as kernel32.lib, user32.lib, and gdi32.lib. Those libraries are probably already included in your linker settings.
By default, Visual Studio includes the most commonly used Win32 .lib files, e.g. kernel32.lib, user32.lib, advapi32.lib etc. For more esoteric libraries, you need to add the .lib files yourself.
By default Visual Studio will link against the standard library, so if you are including a header that is part of that then you don't need to explicitly add the library. This is true for things like stdio.h, iostream and stdlib.h.
There are also some header files such as those used by the Standard Template Library (someone will be along in a minute to say that it's actually just called the 'Standard Library', but most books I've ever read, and Microsoft's docs too refer to the STL) such as <vector> and <list> which define all their code as templates that get expanded into the full functions by the compiler so that they don't need to link in a library.
A slight aside: there's also a mechanism for automatically linking against a library. Just add:
#pragma comment(lib, "ws2_32.lib")
somewhere in your code. Boost uses this technique so that it links against the correct build of the library depending on your compiler settinsg.
This has nothing to do with Visual Studio; this is how compilation of C/C++ works.
All a header does is declare or define symbols. Functions, variables, typedefs, classes, etc.
A header can say:
int SomeFunction();
This is a function declaration. In order for you to compile code that uses SomeFunction, you must declare that SomeFunction exists. And this declaration must be made before your code that uses it.
These declarations are typically in header files.
However, a declaration is also a promise. A function definition is the actual C/C++ source code that makes the function work. A declaration says, "at some later point, you will be able to find the definition of this." This is a promise you are making to the compiler and linker.
You cannot successfully link C/C++ code unless all declarations in use have a definition. Some of these definitions come from your own compiled code, but some of them come from external libraries. External libraries have header files that provide the declaration of C/C++ functions, types, etc. But they also have library files (in VC++, these use the .lib extension) that provide the definition of those functions.
If you use declarations from a header, without linking to the library files that provide the definition of those symbols, you get a linker error.
Note that header files can contain definitions as well; much of the C++ standard library, and must of Boost is defined solely by header files. So there are no libraries to include. The library's documentation should tell you whether there is a .lib to link against or not.