Dynamic Library: Do you need to export variables of a class?
Lets say you have the following class.
Code:
#pragma once
#include <iostream>
#include <vector>
//-_-_-_-_-_-Class Declerations-_-_-_-_-_-//
class Renderer;
class Brain;
class Transform;
//-_-_-_-_-_-Class Declerations-_-_-_-_-_-//
class Sprite
{
//Public Members.
public:
Transform *transform;
std::string tag;
//Private Members.
private:
std::vector<Brain *> m_brains;
//Public Methods.
public:
//Constructor.
__decspec(dllexport) Sprite(std::string imagePath, glm::vec2 position = glm::vec2(0.0f, 0.0f), std::string tag = "");
//Deconstructor.
__decspec(dllexport) ~Sprite();
//Private Methods.
private:
//Render Method.
__decspec(dllexport) void Render(Renderer *rednerer);
};
Do i also need to export the transform and tag variables? Or __declspec only reference to methods and functions?
The reason I'm not putting __declspec before the class name but I manually place it in each method is because i get a link warning
for the std::string tag .I searched on google and they say that you should not export std::base_string templates because they are
already exported. So i tried to fix that by manually choosing which method i want to export.
Also does it make sense to export private Methods?
Re: Dynamic Library: Do you need to export variables of a class?
The simplest answer is don't put a class definition into a .dll - have it in a header like the STL classes. Exporting a class can create all sorts of problems. We stopped doing this years ago. If you must have it in a dll (why?) then in the dll use a factory function that creates a new instance of the class and returns a pointer. The class declaration resides in the header file for compile time. The good rule of thumb for a dll export is to only export 'c' style interfaces (and treat struct as a c struct and not as a c++ struct).
See
https://stackoverflow.com/questions/...and-from-a-dll
https://stackoverflow.com/questions/...lasses-to-dlls
https://stackoverflow.com/questions/...***-from-a-dll
https://www.codeproject.com/articles...ses-from-a-dll
https://msdn.microsoft.com/en-us/library/81h27t8c.aspx
A private method can't be used outside of its class or in a derived class - so how would a private method be used by the calling program?
Re: Dynamic Library: Do you need to export variables of a class?
Quote:
Originally Posted by
2kaud
If you must have it in a dll (why?) then in the dll use a factory function that creates a new instance of the class and returns a pointer.
So basically you're telling me to create something like this?
And if I have multiple constructors I must overload ClreateSprite Function.
Code:
#pragma once
#include <iostream>
#include <vector>
//-_-_-_-_-_-Class Declerations-_-_-_-_-_-//
class Renderer;
class Brain;
class Transform;
//-_-_-_-_-_-Class Declerations-_-_-_-_-_-//
class Sprite
{
//Public Members.
public:
Transform *transform;
std::string tag;
//Private Members.
private:
std::vector<Brain *> m_brains;
//Public Methods.
public:
//Constructor.
Sprite(std::string imagePath, glm::vec2 position = glm::vec2(0.0f, 0.0f), std::string tag = "");
//Deconstructor.
~Sprite();
//Private Methods.
private:
//Render Method.
void Render(Renderer *rednerer);
};
__decspec(dllexport) Sprite *CreateSprite(std::string imagePath, glm::vec2 position = glm::vec2(0.0f, 0.0f), std::string tag = "");
And never do this?
Code:
class __decspec(dllexport) Sprite;
Quote:
Originally Posted by
2kaud
A private method can't be used outside of its class or in a derived class - so how would a private method be used by the calling program?
I was thinking about friends, but even then how can the dll possible know to friend client classes, it's not possible.
Re: Dynamic Library: Do you need to export variables of a class?
Well I tried this but I get link errors.
DLL.h
Code:
#pragma once
#ifdef DLL_EXPORT
# undef DLL_EXPORT
# define DLL_EXPORT __declspec(dllexport)
#else
# define DLL_EXPORT __declspec(dllimport)
#endif
Printer.h
Code:
#pragma once
#include <iostream>
#include <string>
#include "DLL.h"
class Printer
{
public:
std::string m_msg;
public:
Printer(std::string message);
~Printer();
void print();
};
DLL_EXPORT Printer *CreatePrinter(std::string message);
Printer.cpp
Code:
#include "Printer.h"
Printer::Printer(std::string message) : m_msg(message)
{
}
Printer::~Printer()
{
}
void Printer::print()
{
std::cout << m_msg << std::endl;
}
Printer *CreatePrinter(std::string message)
{
return new Printer(message);
}
Client.cpp
Code:
#include <Printer.h>
int main()
{
Printer *p = CreatePrinter("Skata melata");
p->print();
delete p;
return 0;
}
Link Errors:
Code:
1>Source.obj : error LNK2019: unresolved external symbol "public: __thiscall Printer::~Printer(void)" (??1Printer@@QAE@XZ) referenced in function "public: void * __thiscall Printer::`scalar deleting destructor'(unsigned int)" (??_GPrinter@@QAEPAXI@Z)
1>Source.obj : error LNK2019: unresolved external symbol "public: void __thiscall Printer::print(void)" (?print@Printer@@QAEXXZ) referenced in function _main
I don't really understand what you mean. Can you make me an example to see it? Maybe i'll understand this way.
Re: Dynamic Library: Do you need to export variables of a class?
I don't see where you are defining DLL_EXPORT so I don't think you are exporting anything from the dll - hence unresolved symbols.
Shouldn't printer.cpp (as the dll source) define DLL_EXPORT as the first line?
Have you read through the links from post #2?
Good practice for dll interface is to mark it as extern "C" so that the linkage is c as opposed to name-mangled c++. This means that you can only use a 'c' style interface to the .dll - so passing a type std::string is a no-no. You would pass this as type LPCSTR. For a 'c' style interface that's why you use a pointer to a class as opposed to a class itself.
As I indicated previously, if you don't absolutely need to use a dll, its far easier to just put the whole class into a header - especially with inline class methids in c++17 so that multiple compilation units can be used within one solution with the same header file.
Re: Dynamic Library: Do you need to export variables of a class?
Quote:
Originally Posted by
2kaud
I don't see where you are defining DLL_EXPORT so I don't think you are exporting anything from the dll - hence unresolved symbols.
Shouldn't printer.cpp (as the dll source) define DLL_EXPORT as the first line?
I'm defining DLL_EXPORT in the preprocessor definitions of the DLL project in Visual Studio.
Ok I guess there are a lot of things I don't know about c++ and dlls. I need to learn more before continuing. Also I don't even remember what .lib files actually contain, this makes it even harder to understand why I should not export classes.
Re: Dynamic Library: Do you need to export variables of a class?
The more fancy contemporary C++ becomes, the worse effects it causes to dynamic linkage. The old-school C++ from 90s was bearable with certain limitations, not many. Templates have caused a serious damage to dll interface design. But modern C++ must not be let out across binary module bounds, absolutely.
You want to expose some object model from binary module, you go with pure interfaces and no STL in method parameters. You decide to create a dll in C++ project, you think not like twice, but two dozen times. You decide to go with dll, you need to be sure you know what you do and why you do that what you do. And if you're not, you just avoid doing dll.
Re: Dynamic Library: Do you need to export variables of a class?
You need to write the exported DLL functions the same base types as they are defined in the windows api.
Take a look at some windows api fonction definitions in msdn - there are plenty of examples to do anything you need.
Re: Dynamic Library: Do you need to export variables of a class?
Quote:
Originally Posted by
Igor Vartanov
The more fancy contemporary C++ becomes, the worse effects it causes to dynamic linkage. The old-school C++ from 90s was bearable with certain limitations, not many. Templates have caused a serious damage to dll interface design. But modern C++ must not be let out across binary module bounds, absolutely.
You want to expose some object model from binary module, you go with pure interfaces and no STL in method parameters. You decide to create a dll in C++ project, you think not like twice, but two dozen times. You decide to go with dll, you need to be sure you know what you do and why you do that what you do. And if you're not, you just avoid doing dll.
Can you point me somewhere where I can learn about these stuff? I'm completely lost right now, literally I don't have an idea of what you guys are talking about. Maybe a book that teaches you these stuff.
By the way, until now I didn't' have any problems exporting classes. I just put __declspec(dllexport) in each public method and the library was exporting just fine. And the linkage was working like a charm.
Re: Dynamic Library: Do you need to export variables of a class?
Quote:
Can you point me somewhere where I can learn about these stuff?
I did in post #2.
Re: Dynamic Library: Do you need to export variables of a class?
This really helped me! I see now. This made me think that when making a dll it is better to code it in C .
Re: Dynamic Library: Do you need to export variables of a class?
Quote:
Originally Posted by
babaliaris
Can you point me somewhere where I can learn about these stuff? I'm completely lost right now, literally I don't have an idea of what you guys are talking about. Maybe a book that teaches you these stuff.
You just go right to MSDN DLLs in Visual C++ and start right there, I would say. The first answer you are to look up for is not how, but why you need to put a code to DLL. In case you have no real reason to do that, you don't.
First time I heard about dynamic linkage I instantly fell in love with the concept. Lucky me, I had a lot of time to play with the technique and learn those many things about DLLs in practice. I started with Win16 dlls in 1996 and never missed a chance to learn a new trick with DLL programming.
Now, for all those years passed I can remember only a few cases when I really created a DLL in a commercial project:- a global hook DLL for intercepting keyboard events
- an ActiveX add-on for IE
- a COM DLL helping PHP web server with access to specific Win32 APIs
- a DLL module for installer package
- an injectable DLL for debugging a production server in long-term support
- a plug-in for customer's data storage product
Not much for DLL admirer, eh?
Quote:
By the way, until now I didn't' have any problems exporting classes. I just put __declspec(dllexport) in each public method and the library was exporting just fine. And the linkage was working like a charm.
Yep, this means that you built all the solution with the same compiler and STL version. Which means, you hardly needed your code to be put in DLL at all, unless you build an API for people that would agree to comply with those limitations.
The real idea of dynamic library is about being able to safely load to/unload from any process and at any time. Most of the DLLs with C++ exports are loaded at the very process' start and never get unloaded till the very end. You try to load the DLL at arbitrary time and you see the charm kiss you good-bye. You build your C++ DLL with VS 2017 and try to link with VS 2008 EXE and see if the charm is still there. You build your DLL and EXE modules with different memory management modes and see your app fall with no apparent reason. Then you re-define your concept of 'working like a charm'.
Re: Dynamic Library: Do you need to export variables of a class?
The reason I want dlls is for making an upgrade able application for big projects, mostly video games. I don't want every time I'm making changes the user needs to download the whole executable.
Re: Dynamic Library: Do you need to export variables of a class?
Quote:
Originally Posted by
babaliaris
The reason I want dlls is for making an upgrade able application for big projects, mostly video games. I don't want every time I'm making changes the user needs to download the whole executable.
That's a very good reason.
Re: Dynamic Library: Do you need to export variables of a class?
Quote:
Originally Posted by
babaliaris
The reason I want dlls is for making an upgrade able application for big projects, mostly video games. I don't want every time I'm making changes the user needs to download the whole executable.
and why the dll interfaces need to be 'C' and not C++!