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.
Related
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.
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 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.
So for the sake of the argument, I have a module called ExportedFunctions.cpp whith a couple of functions decorated with the DLL_EXPORT (see below)
#define DLL_EXPORT __declspec(dllexport)
ExportedFuncitons.cpp includes a LibraryFunctions.h. The functions declared in that header are implemented in LibraryFunctions.lib and statically linked to my project.
The problem is that when I compile my DLL and look at it using a dependency walker (depends.exe), I can see not only the functions exported by ExportedFunctions.cpp, but also all of the functions in LibraryFunctions.h.
That is the case even if I delete some function declarations from LibraryFunctions.h. They keep showing as DLL entry points. I want to hide them.
Figured it out.
The problem is that the lib file is exporting the functions. It looks like it exports regardless of what the .h file is saying.
Luckily I'm also the owner of LibraryFunctions, so I recompiled it using "Release - Static Lib". In that configuration I block the dllexport directive.
Probably a simple question but I only have Linux to test this code on where __declspec(dllexport) is not needed. In the current code __declspec(dllexport) is in front of all files in the .h file but just in front of like 50% of the functions in the cpp file so I am wondering if they are really needed in the cpp file at all ?
No, its only needed in the header.
Here's a link with more info.
Expanding on what Vinay was saying, I've often seen a macro defined
#if defined(MODULENAME_IMPORT)
#define EXPORTED __declspec(dllimport)
#elif defined(MODULENAME_EXPORT)
#define EXPORTED __declspec(dllexport)
#endif
Then in your header you do
void EXPORTED foo();
set the defines accordingly in the project settings for the project doing the import/exporting.
No, it is not required in cpp file. Only in declaration it is required.
For Example if I have a class CMyClass. If I want to export this then .h will have
.h Server code
__declspec(dllexport) CMyClass
{
};
In the client code i.e., which uses this class you have to forward declare the class as
Client code
__declspec(dllimport) CMyClass;
// Code to use the class
You may use in .cpp file also when you have templated code and you are instantiating in .cpp file then you need to export the definition when it is instantiated. But even in this case, I have seen that doing in .h also works. On windows you can use dumpbin.exe /exports *.dll to see what signatures are exported, there is similar utility in Linux too. This will give you an idea how signature is exported.