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?

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?

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.

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.

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.

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.

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.

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.

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.

Quote:

---

Can you point me somewhere where I can learn about these stuff?

---

I did in post #2.

This really helped me! I see now. This made me think that when making a dll it is better to code it in C .

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'.

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.

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.

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++!

Quote:

---

Originally Posted by 2kaud

and why the dll interfaces need to be 'C' and not C++!

---

Well if I'm compiling the project myself, I won't probably have any problems but if others need to compile it in other operating systems too , from what i read from your links i will have a problem. If i program every dll in C i won't have problems with the compilers right?

If the .exe(s) and the .dll(s) are compiled with exactly the same version of the compiler/stl etc then there shouldn't be a problem. If an .exe or another .dll is compiled with say version w.x.y and this .dll is compiled with version w.x.z then yes, you could well have a problem. If you are distributing .dll(s) as upgrades to big projects you need to have the .dll(s) interfaces as 'C' so that it doesn't matter if the version of the compiler/stl that was used to compile the .dll is not the same as that used to compile the .exe(s).

Now I know everything I need to know! You really helped me all of you. I never expected that dlls would have to much you need to know. A last question. Does the same things are applied to linux shared libraries? Should I search more about it?

Sorry - I can't help you with Linux as I only use Windows/MSVS.