2

I'm just a beginner in c++ and to me this seems like unnecessary code bloat. I understand that dllimport/export are used for sharing dll functionality, but what's wrong with just using public/private accessors?

If i am making a large dll library it seems that I have to go through every single function/class and make sure I export it. With managed dll (like from c#) I don't need to do anything. Import it into my project, and as long as the function is public it's accessible!

Chebz
  • 1,375
  • 3
  • 14
  • 27
  • possible duplicate of [Why/when is \_\_declspec( dllimport ) not needed?](http://stackoverflow.com/questions/4489441/why-when-is-declspec-dllimport-not-needed) – m.s. Aug 14 '15 at 05:54
  • Well I think this is a question for Microsoft, but I guess they would say there's an overhead to exporting something from a DLL, so they are giving you the choice whether to export something or not. I would also add that if you are exporting so much from a DLL that's it's a burden to specify all the exports then maybe your design is faulty? Only a suggestion since I don't know what you are trying to achieve. – john Aug 14 '15 at 05:57
  • Your question has nothing to do with C++. It's just the way Microsoft stuff "works". Are you saying they've figured out how to hide it from the programmer with C#? Good for them. – n. m. could be an AI Aug 14 '15 at 05:58
  • @m.s. Probably not a duplicate, the other question only asks for `dllimport` while this asks about the reasoning behind `dllexport`. – skyking Aug 14 '15 at 06:02
  • @n.m. They had figured it out in the 1980s, with the IMPLIB and .DEF tools. Why they chose to leak it into the C and C++ languages is another question. – user207421 Aug 14 '15 at 06:04
  • 1
    This is not **that** specific to Microsoft implementation, other implementations (that support shared libraries) has similar functionality (although the may use other way of specifying it). – skyking Aug 14 '15 at 06:05
  • @EJP Probably because they have reasoned (somewhat justifiably) that having to specify information about your functions in two or three different places is not that great. – n. m. could be an AI Aug 14 '15 at 06:16
  • @skyking dllexport has parallels in other implementations, but dllimport is a mystery. – n. m. could be an AI Aug 14 '15 at 06:18
  • 1
    For the mystery of `dllimport` you can read about it here: http://stackoverflow.com/questions/4489441/why-when-is-declspec-dllimport-not-needed – skyking Aug 14 '15 at 06:44

3 Answers3

3

Because when you're creating a larger dll (or shared library) you may want to compose it of several object files, but don't want to expose all the public (to the linker) symbols in each object file. That is there are occations when a symbol is public in one of the object file for the only purpose to make it available to another object file in the same library.

Note that public and private accessors are not quite the same as private symbols in an object file. While private symbol in an object (fx created with global static qualifier) file means that the symbol is not visible at all outside the object file, while private accessors just mean that the symbol can't be accessed from outside the class (it still can make it into the object file as public since it could be accessed from the same class within another translation unit).

If you want to export all public symbols in the object files there may be a mechanism to do that without having to resort to explicitely mark each symbol as dllexport - you have to check the documentation, apparently there's a way in microsoft for that.

And for the story about dllimport you can read it here: Why/when is __declspec( dllimport ) not needed?

Community
  • 1
  • 1
skyking
  • 13,817
  • 1
  • 35
  • 57
0

The idea is that your module can have some functionality that only it needs to run which exposing would be pointless. For example, if you have a Timer class you are exporting, and it depends on some global function you wrote to get the current time, you don't need to export said function, since users of your library don't depend on it directly. Sorry about the bad example.. Also, you don't need to export your classes, use interfaces and factory functions.

//IBob.h

#define DLLAPI __cdecl
class IBob
{
public:
     void DoSomething( ) = 0;
};

__declspec(/*export / import*/) IBob* DLLAPI BobFactory( );



//----------------------------------
//Bob.h

#include "IBob.h"
class Bob : public IBob
{
public:
     void DoSomething( ) override
     {
     //implementation...
     }
private:
     int var;
     int var2;
};

__declspec(dllexport) IBob* DLLAPI BobFactory( )
{
     return new Bob( );
}
user5226186
  • 1
0

As said this is nothing to do with C++ and is just the way DLLs work in every language (.NET managed DLLs are different). When the OS loads a program with DLLs it must fix up all references in the EXE to functions exported from the DLL, so the less of them you use the faster the program loads. Probably in this day and age it makes little difference, but this goes back to the early versions of Windows.

BTW you can __declspec(dllexport) a whole class, which is the slightly lazy way of doing it.

Dave Emberton
  • 86
  • 2