So I'm working on some libraries for c++ to make a beginner's experience easier. I've put the libraries into a standalone dll and now i want to add it to another project. But the thing is after searching the internet for ages, i have to have include directories and stuff but all i want is to include the single dll file to the project so the project can access the .h and .cpp files inside. Ik i can just add external jar with java then i can access the libraries in there but how do i do it with c++ in visual studio 2015?
This is not how C++ works (I also assume you're not talking about C++/CX or MC++ - which strictly speaking are not C++)
The C++ language does not define an "Application Binary Interface" - an ABI, which allows linking between binaries. That's an implementation concern.
There are ABIs that support C++, such as COM and CORBA, indeed the latest one is WinRT - itself based on COM.
C++ differs from languages like Java and C# which mandate a runtime which does have an ABI: Java has its .class and .jar files while .NET/C# has its CLR Metadata contained within its assembly (.dll files - which are not the same thing as "real" DLL files).
Note that DLL files generated by the C# compiler are nothing like DLL files generated by your C/C++ compiler toolchain's linker - while they share a common outer format as PE (Portable Executable) files, internally they are radically different: CLR DLLs contain CIL, an intermediate bytecode, whereas "real" DLLs contain native, processor-specific instructions.
The general way to work with other libraries in C++ is to either use them in source-form (as .c and .cpp files included in your project), or as .h header files with .lib (static libraries) which are almost similar to reusable binaries, except they're linked ("compiled into- and merged-with") into your finished binary and cannot be replaced at runtime.
The other way is with Dynamic Linking which requires your runtime (i.e. Win32) to do the runtime linking for you, usually with GetProcAddress - but this only exports C-style functions, not entire objects and classes (and certainly not any C++ templates).
In summary:
You have a DLL and you want to use code inside of it:
Is it a WinRT DLL?
If you want to use pure C++ then you need to use WTL. Beware, this approach is not for the faint-hearted.
Else, if you're okay with C++/CX then you can actually use the "Add Reference" UI in Visual Studio, but be advised, you're no-longer writing "real" C++ anymore.
Else is it a COM library?
(Note that you will need the ATL (Active Template Library) and the IDL definitions of the types contained within, this is the COM equivalent of a header file). You can also use #import and/or use the IDE to generate the actual .h and .c files needed to call COM without too much pain. However you will run into problems if you replace the COM DLL later without rebuilding your program if too many things were changed in a later COM DLL version (see "DLL Hell").
Else is it a traditional native Win32 PE DLL?
All a PE executable has is a list of exported functions and their address locations within the DLL.
Do you want Static Linking or Dynamic Linking?
For Dynamic Linking, do you want runtime resolution (painful, but flexible) or "automatic" linking?
For runtime linking you only need the .dll file and .h files. You will need to manually call GetProcAddress yourself for each function you want to call, then invoke it. An advantage is that you can detect at runtime if a function exists and gracefully handle linking errors.
For automatic linking you will be given a .lib file in addition to the .dll and .h files, the .lib file is a small statically-linked library that contains stubs and other code needed to perform the runtime linking for you without needing to manually call GetProcAddress yourself.
For Static Linking you won't have a .dll file, but a .lib file: known as a "static library". Inside it's a file that contains discretised executable function blobs which your linker will effectively copy+paste into your completed program.
How do you do it like Java? Well, you don't.
A header is required to provide the compiler with the prototypes of the functions and other symbols that are exported from the DLL that you might want to make use of. You may even have multiple header files to logically divide your DLL's code. And since you won't want to hard-code the path to these header files in your source code, you'll want to specify the path to its containing directory as part of your compiler/build options, freeing you to use relative paths.
A LIB file is generally also required, although this is slightly more flexible. Generally, a LIB makes things much easier. It will be generated by the linker when you compile the DLL, and it contains stubs that facilitate linking to functions exported by that DLL. You specify this LIB file in your linker options when building an application that uses the DLL, and things just work. This is called implicit dynamic linking. It's dynamic linking because you're using a DLL, but it's implicit because the linker is handling the dirty work for you.
If you don't want to use a LIB file, you will need to do explicit dynamic linking. This is still dynamic linking because you're still using the DLL, but it's explicit because you have to explicitly write code to load the DLL module and obtain pointers to functions that it exports. Microsoft's build tools provide various features to make this easier, but it's still more difficult than just using the LIB file, which is what I would recommend unless you have a good reason to do otherwise.
Related
I'm working on a C++ solution in Visual Studio 2010. I've a DLL file which is using some standard C++ library functions (such as string or file functions). For some portability reasons I have to compile this DLL with /MT option, so all required runtime library functions will be linked to the released DLL file.
I've another C++ project which is a windows application, this project also compiles with /MT option and generates an standalone exe file. The second project also uses the same standard C++ library functions that are already linked in my DLL (The executable also uses some DLL exported methods).
Now here is my question: Is there any way to tell linker that don't link common runtime functions which already linked to DLL file & don't link these shared parts again in the exe file (e.g. reuse same code for string functions which already linked to my DLL)?
No, you can't do that. Although executable depends on DLL, they can still be considered as separate and stand-alone binary artifacts, each of which should contain required symbols for proper execution.
This is one of the reasons why dynamic linking is preferred. Furthermore, I don't see any problem to link dynamically and redistribute the runtime with your application.
Although Microsoft Visual C Runtime is included on most platforms, there are many different versions of it, some of which are buggy or/and break backward compatibility. Thus, it is always a good idea to distribute the version of msvcr*.dll that you know works for sure with your application.
I don't know how to do the following:
I'm using MS Visual C++ 6.0
I have a Win32 DLL project which is compilable.
I have another project, this time a Win32 Console project which uses
the DLL by including it's header file and linking the .lib file of
the DLL.
Now I want to have another project, similar to the second BUT without using the header file and the lib file.
Is that possible? Everywhere I read you need either dll+lib+h or dll+h. If thought if you know the interfaces, a DLL file is sufficient?
Btw, by "using a DLL" I mean, using the Classes and Functions defined in the DLL.
It is possible if you just have plain "extern C" functions. If this is the case the approach could be loading the dll with LoadLibrary, and then import each function with GetProcAddress, of course you need to know the function signature to create a properly declared function pointer. Using classes per contrary is almost impossible.
If your DLL contains classes, there are good chances that it is a COM component.
If this is the case, the #import directive (that you use like #include) builds some temporary include files containing the interface details. You should use COM to access your objects.
Otherwise, if you have a 'plain' DLL with C++ classes, you could access the exported symbols using linker: instruct it to dump the map (see here), to know the mangled names. But I don't think that's possible to build manually the interface...
It's pointed out by this answer:
Failed to link mysql5.1.39\bin\libmySQL.dll
But I don't understand why,.dll is essentially the same as .lib except for there is only one copy of it used by different processes.
Does it have anything to do with the IDE?I'm using visual c++ 2008 express
UPDATE
Anyone know a free tool to convert .dll into .lib in windows?
You are wrong on two counts. Firstly, DLLs and LIBs (static libraries) are very different beasts. The LIB you are talking about (I think) is the export library, which is simply a list of names in the DLL. This library is typically produced when the DLL is compiled and is shipped with the DLL if the DLL is intended to be linked to by other developers.
To use a DLL with a modern IDE (I don't use VS) you typically include the matching .LIB (export library) in the project. At run-time you must make sure the DLL is available to your program - the simplest way to do this is to put the DLL in the same directory as the executable.
And secondly, DLLs can be used with C++.
DLL are specific windows executables which load on runtime. Their equivalent in Linux is the *.so .
If you want to understand what's the difference between a DLL and a static lib see here.
Main reason has probably something to do with dll-file being an output of the linker (link.exe). This command line utility doesnt know how to read dlls, only how to write them.
Actually sometimes .lib-files contain more than a list of functions. For example libpng.lib works as a standalone file, without any dll file.
In order to use a DLL in C/C++ you need to link with what is called an import lib. This is a small .lib that contains the names/ordinals the DLL exports in a format that the linker understands. Once this has been linked in, the resulting binary will be able to use the DLL. If you do not have the appropriate import lib, your C/C++ compiler should come with a tool to generate one from the DLL.
You can use the following analogy to understand the difference between a dll and a lib file.
the dll is like the source .cpp file while the lib is the header .h file.
While this is not exactly true, the DLL holds the executable code while the LIB file tells the linker how to glue the code together.
It is also possible (in some cases) to generate the lib from the dll. Basically, all you need to know to call a function is the function entry point in the dll, the number of parameters and the size of each parameters. Sending relevant information is then your own problem.
I'm learning C++ and came across those *.lib files that are obviously used by the linker. I had to set some additional dependencies for OpenGL.
What exactly are library files in this context used for?
What are their contents?
How are they generated?
Is there anything else worth knowing about them?
Or are they just nothing more than relocateable object code similiar to *.obj files?
In simple terms, yes - .lib files are just a collection of .obj files.
There is a slight complication on Windows that you can have two classes of lib files.
Static lib files essentially contain a collection of .obj and are linked with your program to provide all the functions inside the .lib. They are mainly a convenience to save you having as many files to deal with.
There are also stub .lib which provide just the definitions of functions which are contained in a .dll file.
The .lib file is used at compile time to tell the compiler what to expect from the function, but the code is loaded at run time from the dll.
.lib files are "libraries" and contain "collections" of compiled code so-to-speak. So it is a way to provide software components, without giving away the internal source-code for example. They can be generated as "output" of a "build" just like executables are.
The specific contents depend on your platform / development environment, but they will contain symbols for the linker to "hook up" function-calls provided by e.g. the header-file of the library.
Some libraries are "dynamic" (.DLL's on Windows), which means the "hooking" of function-calls is setup when the executable using the library is loaded, allowing the library implementation to be changed without rebuilding the executable.
One last thing. You say you're learning C++, and a common confusing point is, that "symbols" generated by C++ compilers are "mangled" (in order to allow e.g. function overloading), and this "mangling" is not standardized across different compilers, so libraries often resort to C for the "API" of the library (just like OpenGL), even though the library may be implemented in C++ internally.
I hope shed some light on .lib-files. Happy OpenGL coding :-)
What exactly are library files in this
context used for?
They are compiled and linked code just like your executable. They're called static libraries that other programs can link to at compile time. In the case of OpenGL, you link to their libraries to build an executable that can run OpenGL code. Dynamic libraries (DLLs) are another type of library that executables link against, except at runtime.
What are their contents?
Static libs contain linked object code just like an exe. The *.obj files are the object code that the compiler generates for the linker.
How are they generated?
When the compiler creates the object files, it passes the work to the linker. You can create them in your development environment, just like executables.
Is there anything else worth knowing
about them?
Yeah, they're used everywhere, so it doesn't hurt to get used to them.
I know that if I have an .a or .so file and a header file for that library (for example for SystemC), I should
1. include header file
2. link the appropriate library.
But I can't handle with only .dll file as I can link it as well, but don't have a hearer file to include and to use commands. Con someone explain me what kind of .dll-s exist and how they are possible to use? Is it possible to use any .dll file or it should be a specific kind of .dll to be able to integrate to my application?
A DLL is functionally equivalent to a .so file (also know as a 'shared object' or 'shared library'). You need a header to declare the functions that are available inside the DLL and you need to link against a library which handles the business of loading and executing DLL calls (mostly delegated to the OS).
It is possible to use a DLL without any sort of header. You can directly call Win32 API's which will dynamically load a DLL into your programs virtual address space and call other API's which will give you what are essentially function pointers. However, you need to know the signatures of the function pointers to use the properly so what you're effectively doing in that case is declaring a tiny subsection of the actual DLL header for your use.
This wikipedia article may help, especially the section on shared libraries
Unlike Linux, Windows libraries are seperated into two forms: DLL (for runtime linking) and LIB for symbol declarations. link.exe (the windows linker) expects .lib files to resolve symbols being used by your program's headers during build time. More information here:
http://msdn.microsoft.com/en-us/library/ba1z7822(VS.71).aspx
Note that if you load a DLL compiled in C++, you hvae to avoid passing object pointers across the interface, as they are in general not portable. You have to keep to basic C calls and calling conventions, as that is what is defined by the Windows or Linux platform ABI.