I'm new to C++ and I'm having a hard time getting my dll references to work. I've been trying to get it to work for a couple of days, but the few explainations I've found often refer to doing x or y, but don't tell me how to do x or y. Since I'm not a C++ veteran, I need someone to walk me through it. What I want to do is the following:
MySolution
MyExe (Win32 .exe)
Main.h
Main.cpp
(constructs ImplementationB calls the methods as defined by InterfaceA, then deletes the instances)
(calls/fills HelperC.Foobar)
MyInterfaces (dll)
InterfaceA.h
~InterfaceA();
virtual void DoSomething();
MyUtils (dll)
HelperC.h
static float Foobar;
HelperD.cpp
float HelperC::Foobar = 1.0f;
MyImplementations (dll)
ImplementationB : InterfaceA
(uses the value from HelperC.Foobar)
The MyExe and MyImplementations projects contain most of the executing code. But, I need an interface, so I need an interface project (MyInterfaces). I need some helper classes that need to be accessible from both MyExe and MyImplementations, hence MyUtils. I would like this helper class to be statically available, though it is not mandatory.
I had a compiling version before I started adding MyUtils with the HelperC class. I had to mark the interface destructor with __declspec(dllexport), along with the DoSomething method. I also had to mark the constructor of ImplementationB in order to instantiate it from MyExe, which makes sense. However, when I tried to mark the entire class (both the implementation and the interface) with __declspec(dllexport), the example wouldn't compile (which does not make sense).
From what I've read, having static fields in a dll and using them from external code doesn't really work all too well. So, as an alternative, I made Foobar non-static and passed a HelperC instance to the method as described by InterfaceA. Since I had already gotten simple classes to work, I figured that should work as well. However, now the compiler is throwing errors on the constructor of ImplementationB (LNK2019).
In short: I'm getting link errors all over the place in sections that have nothing to do with my changes, and there's little documentation describing the specific steps I need to perform in order to get a simple dll reference to work.
Can someone point out what I need to add and where I need to add it in order to make it compile? Also, some do's and don't's about C++ dll references would help a lot (e.g. don't use statics across projects).
After much digging, I found out that the culprit was a magical project setting. It is called Ignore Import Library and is located at Project Properties->Linker->General, and is set to Yes by default, while it should be set to No in most cases. The setting tells the executable project to use the dll's lib file during compilation. This still sounds strange to me (sounds like duplicate build output), but as far as I understand it, the lib file describes how to link to the dll. If your dll produces a lib during build, you probably want to set the setting to No.
I also learned that to be able to use the HelperC class as a statically accessible helper, I needed to use dllimport in combination with the macro trick, as described by #drescherjm. The dllimport declaration is only ever needed to be able to use data members across libraries (static class fields or globally defined variables). It may be applied to functions as well, though it is not required, in which case it provides a slight performance boost during library linking.
For completeness, my project structure after getting it to work:
MySolution
MyExe (Win32 .exe, Debugger Type=Mixed)
Main.h
Main.cpp
(constructs ImplementationB calls the methods as defined by InterfaceA, then deletes the instances)
(calls/fills HelperC::Foobar)
MyInterfaces (dll, Ignore Import Library=Yes, because there is no .lib after building)
InterfaceA.h
class __declspec(dllexport) InterfaceA
~InterfaceA() {};
virtual void DoSomething() = 0;
MyUtils (dll, Ignore Import Library=No)
HelperC.h
class __declspec(dllimport/dllexport) HelperC // (see macro trick)
static float Foobar;
HelperD.cpp
float HelperC::Foobar = 1.0f;
MyImplementations (dll, Ignore Import Library=No)
ImplementationB.h
class __declspec(dllexport) ImplementationB : public InterfaceA
ImplementationB();
~ImplementationB();
void DoSomething();
ImplementationB.cpp
ImplementationB::ImplementationB() {};
ImplementationB::~ImplementationB() {};
ImplementationB::DoSomething() { /* Omitted */ };
(uses HelperC::Foobar in implementation)
On a side note: if you added a default C++ class library project in Visual Studio, you may need to flip the Project Properties->Debugging->Debugger Type setting to Mixed before you will be able to set/use breakpoints in the dll code. See this.
I hope this helps others who are wrestling with dll's in C++ (and Visual Studio).
Related
Let's say I have this lib
//// testlib.h
#pragma once
#include <iostream>
void __declspec(dllexport) test();
int __declspec(dllexport) a();
If I omit the definition for a() and test() from my testlib.cpp, the library still compiles, because the interface [1] is still valid. (If I use them from a client app then they won't link, obviously)
Is there a way I can ensure that when the obj is created (which I gather is the compiler's job) it actually looks for the definitions of the functions that I explicitly exported, and fails if doesn't ?
This is not related to any real world issue. Just curious.
[1] MSVC docs
No, it's not possible.
Partially because a dllexport declaration might legally not even be implemented in the same DLL, let alone library, but be a mere forward declaration for something provided by yet another DLL.
Especially it's impossible to decide on the object level. It's just another forward declaration like any other.
You can dump the exported symbols once the DLL has been linked, but there is no common tool for checking completeness.
Ultimately, you can't do without a client test application which attempts to load all exported interfaces. You can't check that on compile time yet. Even just successfully linking the test application isn't enough, you have to actually run it.
It gets even worse if there are delay-loaded DLLs (and yes, there usually are), because now you can't even check for completeness unless you actually call at least one symbol from each involved DLL.
Tools like Dependency Walker etc. exist for this very reason.
You asked
"Is there a way I can ensure that when the obj is created (which I gather is the compiler's job) it actually looks for the definitions of the functions that I explicitly exported, and fails if doesn't ?"
When you load a DLL then the actual function binding is happenning at runtime(late binding of functions) so it is not possible for the compiler to know if the function definition are available in the DLL or not. Hope this answer to your query.
How do I (programmatically) ensure that a dll contains definitions for all exported functions?
In general, in standard C++11 (read the document n3337 and see this C++ reference), you cannot
Because C++11 does not know about DLL or dynamic linking. It might sometimes make sense to dynamically load code which does not define a function which you pragmatically know will never be called (e.g. an incomplete DLL for drawing shapes, but you happen to know that circles would never be drawn in your particular usage, so the loaded DLL might not define any class Circle related code. In standard C++11, every called function should be defined somewhere (in some other translation unit).
Look also into Qt vision of plugins.
Read Levine's Linkers and loaders book. Notice that on Linux, plugins loaded with dlopen(3) have a different semantics than Windows DLLs. The evil is in the details
In practice, you might consider using some recent variant of the GCC compiler and develop your GCC plugin to check that. This could require several weeks of work.
Alternatively, adapt the Clang static analyzer for your needs. Again, budget several weeks of work.
See also this draft report and think about C++ cross compilers (e.g. compiling on Windows a plugin for a RaspBerry Pi)
Consider also runtime code generation frameworks like asmjit or libgccjit. You might think of generating at runtime the missing stubs or functions (and fill appropriately function pointers with them, or even vtables). C++ exceptions could also be an additional issue.
If your DLL contains calls to the functions, the linker will fail if a definition isn't provided for those functions. It doesn't matter if the calls are never executed, only that they exist.
//// testlib.h
#pragma once
#include <iostream>
#ifndef DLLEXPORT
#define DLLEXPORT(TYPE) TYPE __declspec(dllexport)
#endif
DLLEXPORT(void) test();
DLLEXPORT(int) a();
//// testlib_verify.c
#define DLLEXPORT(TYPE)
void DummyFunc()
{
#include testlib.h
}
This macro-based solution only works for functions with no parameters, but it should be easy to extend.
I'm writing this Editor.exe program that loads a game.dll, gets the address of a function inside the dll, and pass a pointer to a Core object.
gameInitFuncPtr init =
(gameInitFuncPtr) GetProcAddress(LoadLibraryA("game.dll"),"gameInit");
init(&core); // core is already instanced somewhere, maybe on the stack
The game.dll includes the core.h where the Core class is defined.
The Core class is implemented and compiled into Editor.exe.
On the dll side, calling functions from the passed object pointer, results in an Unresolved external symbol
An example of a call the game.dll would do with the given object pointer would be:
void gameInit(ldk::Core* core)
{
_core->renderer.drawText("initializing...");
}
How can I compile the dll so that it does not try to find, for example, the drawText() implementation within the dll module ?
1 - Please, note that this is NOT a question about how to declare pointers to member functions.
2 - I know it could easily be fixed if i passed a struct with only pointer to the methods, but I'm really curious about this.
3 - I'm using Microsoft's cl compiler 18.00, the one that ships with Visual studio 2013
It is not clear where you initiallize _core. At first glance gameInit should do it.
Declare interface class Core, i.e. it should be abstract. Implement it in a successor class for example CoreImpl in exe. This will fix Unresolved external symbols.
Looks like I was overthinking it.
Wen compiling the editor.exe the Core sould be declared just link any class.
struct Core
{
struct Renderer
{
void drawText(const char* text);
}
...
}
But, since the editor and the game.dll share the same Core.h, I used a macro to modify the declaration of Core.h member functions to be pure virtual, for example:
struct Core
{
struct Renderer
{
virtual void drawText(const char* text) = 0;
}
...
}
So the Unresolved external symbol linking error is gone
BUT: I does not work as expected in RUNTIME! :(
I had a similar problem as you with almost the same setting - Game as dll and Engine as exe. Here are some notes on how to tackle this problem.
Call only virtual methods. As you pointed out, if the method you call is not declared virtual, the linker tries to find an implementation for it and fails (if it's not in the header - a thing we try to avoid). The method does not need to be abstract, virtual is enough. Also, note that in your struct Renderer you can have methods that are not virtual, as long as you don't call them from the dll (if you do, the linker complains). It is probably not advisable to have such an interface, it would be much better to have some sort of API class which has only virtual public methods so users of this class cannot make a mistake.
All classes used from the dll need to be shared or header only. What I mean by this is, that as far as I know, there is no magic way, to have classes declared in header, implemented in cpp which is compiled to the exe and then use these classes from the dll. E.g., if you have a custom string class, it needs to be in a shared library. If it's just in the exe you will not be able to instantiate it in the dll (return it from functions etc.). A solution to this is to use header-only classes. E.g., your string may be implemented in a header in the Editor project and this header may be included by your Game project. This way you essentially compile the same code to both exe and dll.
To see a small working example see my repository with VS 2017 solution which demonstrates this exact problem and nothing else. repo link.
Much larger working example of this problem can be seen in idTech4 engine - DOOM 3 version here. It also uses a game as a dll and an engine as an exe. And also needs to exchange pointers to the engine's systems which are used from the game. The project is big, but if you take a look at project Game-d3xp class Game.h all the way down, they have the game's API with a single function GetGameAPI_t which expects to get gameImport_t struct with pointers to engine systems and returns gameExport_t with game informations. The loading then happens in the Common.cpp
As you can see they use shared library idLib in the respective project for things such as idString. All engine classes used from the dll are usually very small and implemented in headers only (they are mostly structs).
Note that id themselves are moving away from this architecture and even their latest version of DOOM 3 - DOOM 3 BFG edition compiles to a single exe and the modules are static libraries instead of dlls.
I am trying to handle a project with multiple dynamic libraries, in the libraries some global objects are created and registered in a list so that the executable can use them to build other things. In the executable there's no reference to any function of any library, it just needs the objects, and then it knows what to do. These libraries are intended to work like plugins that are chosen at link time.
Ideally when compiling ExecutableProject I link LibraryA, an object of type A gets created (by some code that's compiled in the library) and ExecutableProject does things because of it, using functions in LibraryA. If instead I link LibraryB then an object of type B gets created and other things happen.
The problem is, since ExecutableProject does not directly use any function or class in the library, the library is not loaded, and objects are never created.
I have found some workarounds:
I can use /INCLUDE:symbol at link time when compiling ExecutableProject, where symbol is any symbol exported in LibraryA or LibraryB. I don't like this because I have to know the decorated name of a function in the library, which is not always available. Also, it's not elegant.
I can use a dummy variable. I could put __declspec(dllexport) int force_link_A_or_B; in LibraryA and LibraryB and __declspec(dllimport) extern int force_link_A_or_B; in ExecutableProject. I don't like this because if I had more libraries I'd have to add a variable for each of them. Basically although the code in ExecutableProject does not know which libraries will be linked, it still needs to know how many of them can be linked together.
On Linux, using gcc and ld, it's very easy to solve this problem, all it takes is a simple linker flag -Wl,--no-as-needed. Is there any way to do this using Visual Studio? I would be happy if there was something that worked like /INCLUDE but used entire libraries instead of symbols and did not need decorated names.
Thanks
EDIT: I have been asked to clarify how this design is intended to work. Ideally, when I compile ExecutableProject I link LibraryA or B and an object is created.
`ClassA A;`
This is placed outside all functions in a source file that is compiled in LibraryA. Same thing happens in LibraryB. The key here is that ClassA and ClassB inherit from a BaseClass that ExecutableProject knows well. When the object is created, the BaseClass constructor is run, and inside it a BaseClass* pointer pointing to this (therefore the derived object) is saved, and ExecutableProject uses that pointer. It does not need to know anything about the derived classes, because it uses only a BaseClass pointer, but when it calls virtual functions from it, different functions are executed depending on the actual type of the pointed object. If there were more objects instead that just two alternatives, I would save BaseClass pointers in a list or a map, and let ExecutableProject access it.
Don't try this. The design is fundamentally flawed.
In particular, since you are not making any explicit calls to the DLL, you would rely only on object A being created via an implicit call to DllMain.
But under Windows rules, you are barred from doing anything interesting in or from DllMain, so object A cannot be very useful.
This question might be similar to
DLL Exports: not all my functions are exported
but as it was not fully answered there, I have to ask again. Also my case is because of the use of templates and exporting the whole classes slightly different.
Used environment: VS2008, cl9.0.
I have created a dll-project and added about 40 files (each class a file), mainly headers, because a lot of the classes are templates. An example of the heritage would be:
// Class1.h
template<class TYPE>
class TInt
{
// Some member functions here
// Also a function bool IsValid() const;
};
// Implementation of template here in the header
// Class2.h
#ifndef DllExpImpM
#define DllExpImpM __declspec(dllimport)
#endif
class DllExpImpM CInt : public TInt<double>
{
// Some member functions here
};
// Class2.cpp
// Some includes, including "stdafx.h", which sets DllExpImpM
// to __declspec(dllexport)
template class DllExpImpM TInt<double>;
// Implemenation of CInt
So far, it worked fine as long as I used the debug (compile) option. I was able the use the dll project from other projects.
But if the dll projekt is compiled as release (which works fine), I cannot use it from other projects, because the compiler complains that are some missing functions, e.g. that IsValid() in TInt. I used the dependency walker to check it, and indeed, the compiler is right! The member function IsValid() was not exported, along with another function and with a constructor und the destructor. All other member functions of TInt are exported, I can see them using the dependency walker, I can use them from other projects. This also happens in a similar way with one other class.
I then compared the debug dll and the release dll using the dependency walker and winmerge. They are almost identical, just that the release dll is missing a few functions (about 3 %).
I have no idea what is wrong. I know that I do not have a lot information (the whole information is much too big and I yet could not find a simple example that does not work) and to me all sounds a little bit weird. But perhaps anyone out there once had the same problem. I appreciate every idea very much.
Thank you!
If it works for debug, but not release, then you need to identify what is different. My first guess would be that a #define macro or an equivalent /D macro us not getting defined or is getting defined wrongly.
Maybe DllExpImpM or maybe something else.
If not a macro, then what else changes between builds?
Here are some things I found when I ran into this.
I had the same issue, but taking off the /GL parameter didn't make any difference.
My first test was creating a very simple funcion - void test () - and trying to export it. That didn't work until I got rid of the whole output directory (x64 in my case) and rebuilt it all. It would guess that some intermediate file was messing my compilation, anyway, I didn't investigate it further.
But there was still one function that wouldn't be exported. I took some time to realize the declaration in the .h file wasn't matching exatly the signature in the .cpp file! I was missing a parameter in the .h file... I don't know why it was even compiling, anyway, fixing that allowed the function to be exported.
I use several 3rd party libraries like boost, I have one class in my project, let's say it called "MyClass"
All the public functions of "MyClass" use only standard types (int,char,string), but the private functions use smart pointers from boost, and other algorithms from other libraries.
So before i write the declaration of the class (and it's functions) in the H file i write several include files.
To make the project compile i add some Additional include libraries to the project properties.
And everything works fine.
The problem is that when i want to use this class from another project called USERPROJECT (the class is extern) i need to include the MyClass.h file in the USERPROJECT project, and then nothing will compile because MyClass.h includes boost and other things that are not configured in the USERPROJECT (i didn't configure the additional include libraries here, and i don't want to because he doesn't need to know them, they are in the private functions of the MyClass class).
What i the solution ?
should i split MyClass to 2 class one for interface and one for implementation ?
should i remove all the includes from the H and MyClass and use forward declaration ? (i tried but failed to compile it)
is there a better solution
Thanks in advance
You can create compiler firewalls by using the pimpl idiom:
// header file
class C
{
public:
...
private:
struct Impl;
boost::scoped_ptr<Impl> m;
};
// cpp file
struct C::Impl
{
// data member that were in C previously go here //
};
This way the code using your header file does not see the guts of your class. This idiom is explained in detail here. However, you can still get linking errors, if you use boost libraries that need to be linked in. If you use header-only parts of boost only, then there should be no problem.
The ideal is that every external component is accessible in every project. (And all are compiled with compatible options, etc).
If you can push toward that, your problem will be solved. And problems of other people around who wanted to use boost but faced this same impediment.
If you can't do that, you might still have solution using pimpl, but it is adds a deal of complexity, maintenance overhead and reduces readablity to some extent. And depending on what you use from boost, may only solve the compile part of the issue, as linking may require some extra lib. (unless your thing is self-contained, like a DLL)
For the latter case, if linking happens at client site, smuggling the lib is mandatory, but then it's the same amount of work to have the full boost, and avoid the chaos. So before action do some research.