My VS2012 Solution contains several VC++ projects.
I also have many common files that need to be shared.
It's easy to share enum's and structures. I just "include" corresponding header file and that's it. I even don't need to compile my "commons" project!
But what if I need to share more complex classes that contain both .h and .cpp files, and so need to be compiled?
And the most complicated question - can I share thread-safe singleton? I want to access it from different projects from different threads (but from one process).
I guess I should use something like static or dynamic linking, but i'm not sure. Probably someone can link step-by-step tutorial to solve such problem?
I would prefer something portable as I will move entire solution to Linux later.
The projects that contain classes that you want to share should export their symbols. When you create a DLL project in Visual Studio you can give it the option to "Export" symbols and it provides some boiler-plate code for you to use.
In essence, in your libraries header file, it will give you:
// myapi.h
#if defined(MYAPIEXPORTS)
#define MYAPI __declspec(dllexport)
#else
#define MYAPI __declspec(dllimport)
#endif
'MYAPIEXPORTS' is provided by the wizard, but it's a compiler preprocessor directive ONLY on the library itself. Hence when you compile the library, MYAPI is for exporting and when the header file is included in your other projects, it will be for importing.
Now let's look at a class you want to share.
// myclass.h
class MYAPI MyClass
{
public:
MyClass();
~MyClass();
};
// myclass.cpp
#include "myClass.h"
MyClass::MyClass() { /* ... */ };
MyClass::~MyClass() { /* .... */ }
Your other projects then need to link with the resulting .lib file that is generated.
Note that if you have a template<> class contained entirely within a header file, you do not export it. That will behave like your enums and typedefs.
To answer the second part of your question, yes a singleton defined in your library will be accessible to the main project also.
Related
Create a “Dynamic Linked Library with exports” project (Test.vcxproj).
Replace the predefined class with the class below.
Delete the implementation of predefined classes and #include "Test.h".
Build.
Drag the DLL in Dependency Walker -> Nothing is exported.
The class is exported if you use the header, or implement the destructor, in a CPP file.
I have noticed this behavior a long time ago but I forgot about it. Today I had a hard time trying to understand, again, what it is happening.
I do not see why this is normal since the header is part of the project.
Thank you.
class TEST_API CTest
{
public:
virtual ~CTest() = 0 {}
};
Referencing the header in the project file is a red herring. You can, indeed, exclude it from the base working example and everything still works. The actual files being processed are the .cpp files.
DLL imports and exports are generated by the compiler (and later used by the linker) when encountering __declspec(dllimport) and __declspec(dllexport) attributes, as used in your class. However, since no .cpp file includes your header, the compiler never encounters your class at all. Hence, no export.
Note that, even if your class ends up in a compiled file and the exports appear, your destructor is implicitly inline and thus a user of the library might (or will, I'm not 100% sure) generate and use its own definition rather than importing the one from the DLL.
I have a dll, which accesses some classes outside of its project (I'm using Visual Studio, so I have two projects). The thing is, in the header that the dll includes, which is outside of the dll's project, there are only bodies of functions, like this:
x.h
class x
{
void myFunc();
}
And in another cpp file, outside of the dll file:
#include "x.h"
x::myFunc()
{
//.....
}
The dll is only getting the bodies of the functions, so when I compile, I get lots of unresolved external symbols (I'm quite sure that this is the issue, because I tested with another class fully built in a .h file, in another project, and no errors). So how can I solve this mystery?
It is normal for the import headers to only have function signatures; the actual function bodies are already compiled into the DLL binary and are resolved at link time by linking into the actual DLL.
The first thing to try is to make sure you are actually linking to the said DLL. It isn't enough to just include the header, you also need to link to the binary. So in your project configuration, you need to add a link to (for example) the .lib file that gets created along-side the DLL when the DLL is compiled (if in MSVC). This lib file lets the linker know how to connect the function signatures you included via the import header to the actual implementations contained in the DLL. If you're on a different platform, the mechanics might be a little different, but the concepts will be similar.
Edits:
The next step is to make sure the binary is actually exporting the symbols you're trying to link against. Make sure that all interface signatures are being exported via __declspec(dll_export) prefixes. Normally this is wrapped up in an IFDEF so that the header is declared export while the DLL is being compiled, but not when that header is included in a client project. Next, you could use dumpbin to check the mangled export names, and see if there is anything unexpected.
Here's a modified version of your example that illustrates this style of export (note, I haven't tested if this compiles, apologies for any typos):
#ifdef BUILDING_MYDLL
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif
class MYDLL_API x
{
void myFunc();
}
You would then set your configuration to define BUILDING_MYDLL when compiling the dll, but not when compiling the executable. This way the functions are only marked export when compiling the library dll. Now you can mark your public API functions with MYDLL_API and they should get exported during build.
Please note that dll_export, dll_import, and declspec are all very MSVC-specific constructs. Other compilers/runtimes handle symbol export in different ways.
There's multiple ways to link DLL into your app on Windows, check out this existing question/answer:
https://stackoverflow.com/a/2060508/1701823
I am having trouble with a dll I am writing in C++. There is some very strange behavior going on that I have not been able to solve on my own.
It's hard to describe exactly what's going on, but I will try my best. Basically I have a class in my DLL with a single private property and a public constructor. When I initialize this class and then exit the program I get an error.
"Run-Time Check Failure #2 - Stack around the variable 'test' was
corrupted"
I have 2 projects here:
The DLL named "testdll".
The console test program named "test".
I have boiled this error down to its simplest reproducible form to try and narrow down the possible causes, below you will find my code.
Project "testdll", file testdll.h:
#include <string>
class testdll
{
public:
__declspec(dllexport) testdll(); // Empty but same error if prams are used.
private:
std::string _var;
};
Project "testdll", file testdll.cpp:
#include "testdll.h"
testdll::testdll()
{
}
Project "test", file testdll.h:
#include <string>
class testdll
{
public:
__declspec(dllimport) testdll();
};
Project "test", file stdafx.h:
#pragma once
#include "targetver.h"
#include <tchar.h>
Project "test", file test.cpp:
#include "stdafx.h"
#include "testdll.h"
int _tmain(int argc, _TCHAR* argv[])
{
testdll test;
return 0;
}
If you want I can send you the Visual C++ 2010 solution file, in the archive format of your choice. Please help! I have no idea what's going on.
Optional Information:
Language (or Software): C++
Already Tried:
Deleting the constructor definition, which works but is not a usable solution, nor does it explain the problem. Also making all of my private properties into pointers works, however I should not have to do this.
You are using two header files, they don't declare the same class. One has a std::string member, the other doesn't. That's very very bad, the compiler doesn't reserve enough space for the object on the stack frame. Which is what the runtime error is telling you. Very nice feature btw, this kind of mistake is incredibly hard to diagnose otherwise.
You probably got into this pickle because you only applied __declspec(dllexport) to the constructor instead of the entire class. You'll need to write the header file so it can be used by both your dll project and your exe project. That should look like this:
#undef DLLEXPORT
#ifdef BUILDING_MYDLL
# define DLLEXPORT __declspec(dllexport)
#else
# define DLLEXPORT __declspec(dllimport)
#endif
class DLLEXPORT testdll
{
public:
testdll();
private:
std::string _var;
};
Right-click your DLL project, Properties, C/C++, Preprocessor, Preprocessor Definitions. Append BUILDING_MYDLL
And delete the testdll.h file in your exe project directory. Set the C/C++, General, Additional Include Directories setting so the compiler can find the header in the testdll project directory (like ..\testdll)
Exporting classes and class members from a DLL is very VERY fragile, as you have just discovered. If the library and client don't both use the exact same class layout, which depends on all kinds of compiler settings, things fail horribly.
In your case, you're probably using incompatible versions of std::string inside class testdll. Maybe one is compiled for debug and one for release. Or one is using the static runtime library and the other the DLL runtime. Who can say?
Anyway, as soon as you export C++ features from a DLL, you lock yourself in to that compiler version and settings. It's a maintenance nightmare.
Use v-table-only base classes or C-compatible wrapper functions.
I am using dev c++. also i am getting assistant from a library, developed by somebody else for my own c++ projects. i have added two new classes called TriangleList and TriangleLists to the library as i wanted new class types for the project. once, i added the hpp and cpp files to the library, i got the massage like creating ../lib/libExtraction.a .
however, when i called back the functions, that i written in the new classes, from my own project, i got the error massages like
`[Linker error] undefined reference to `TriangleLists::Erase()`
(the above one for the Erase function)
then, when i removed the .cpp file and wrote everything in .hpp it works.
But, i would like to maintain two files for the hpp and cpp further. so, please tell me how to solve this link error problem as i want to learn this. thank you in advance.
First thing you need to check is if you're exporting the class:
class __declspec(dllexport) TriangleLists
{
//members
};
When you include the header in a different project however, you need to specify that the class is imported, so:
class __declspec(dllimport) TriangleLists
{
};
This is usually achieved with preprocessor directives:
#ifdef BUILDING_FIRST_PROJECT
#define DLLIMPEXP _declspec(dllexport)
#else
#define DLLIMPEXP _declspec(dllimport)
#endif
//TriangleLists.h
class DLLIMPEXP TriangleLists
{
}
and only define BUILDING_FIRST_PROJECT in your first project. That way, when building the first project, you'll be exporting the class, and when you include the header in another project, you're importing it.
Second thing is that the other project must link to the .lib file generated by the first project.
The reason it works when you move the implementation to the header is that the method becomes inline, so there's no lookup for it in the lib files, as it's definition is already known.
I have a bunch of Dll's in my project, using VStudio 9.0 compiler, pre-compiled headers are used for all my Dll's. The dll's loading process is done by implicit caller (.dll, .lib and header must be supplied).
I typically create a different macro definition file per dll, for instance if my current Dll is called MYMacroDll I add a file _MyMacroDll.h which contains:
#ifndef _MYMACRODLL_H_
#define _MYMACRODLL_H_
#ifdef _WIN32
#ifdef MYMACRODLL_EXPORTS
#define MYMACRODLL_API __declspec(dllexport)
#else
#define MYMACRODLL_API __declspec(dllimport)
#endif
#define MYMACRODLL_CALL __cdecl
#else
#define MYMACRODLL_API
#define MYMACRODLL_CALL
#endif
#endif
I know the code can be simplified but I keep the last defines for portability, at least, that's what I understood...
The pre-compiled header file pch.h, will always include the macro definition file _MyMacroDll.h, this makes things easier to me, 'cause later I can decide whether a new class or function will be interfaced or not. This so far works correct.
The confusion comes from using the dll interfaces in another dll; let's suppose a second dll ImageLoaderDll. This one uses instances or references of one (or several) of the interfaced classes/functions in _MyMacroDll. At first glance I guessed there was no need of including the _MyMacroDll.h, but when compiling the ImageLoaderDll it complains with
error C2470: '_AnInterfaceClassFromMyMacro' : looks like a function definition, but there is no parameter list; skipping apparent body
Then I have to include the _MyMacroDll.h in the pre-compiler header file of the other Dll, my project is becoming really messy and I find more and more useless dependencies.
What am doing wrong? Is there another way of setting up the macro definitions so I can avoid adding it to the client Dll's? Am not an expert regarding software design, but in this situation the more decoupled the better.
Hope my explanation was good enough.
If you are using the DLL interface from MyMacroDll in ImageLoaderDll, then you do have a dependency. ImageLoaderDll should include _MyMacroDll.h, otherwise you can't call its functions correctly. It's exactly the same as including <string.h> when you want to call strlen.