How to declare a class shared between a library and an application

Question

I have a common utility class that is shared between two projects, an desktop application project and a library project (dll). I'm working under VS2013.

To make this class available to external calls when it's compiled as part of my library, I use a macro like this:

#include "global.h"

class MYCLASS_EXPORT UtilityClass {

public:
...

My global.h file contains the following:

#ifdef MYCLASS_LIBRARY
# define MYCLASS_EXPORT __declspec(dllexport)
#else
# define MYCLASS_EXPORT __declspec(dllimport)
#endif

So when I use that class inside my library I set the preprocessor macro MYCLASS_LIBRARY and an application that link my library can use the UtilityClass.

Instead, when I use that class as part of my C++ desktop application project (that doesn't have the preprocessor macro MYCLASS_LIBRARY), I get from the compiler an "inconsistent dll linkage" error because of MYCLASS_EXPORT declaration.

So, how to declare my class so that can be used both in a library project and in a desktop application project (so without the need to export that class)?

Just to be more clear, a working solution I've found is the following:

#ifdef MYCLASS_LIBRARY
 #include "global.h"
#endif

#ifdef MYCLASS_LIBRARY
    class MYCLASS_EXPORT UtilityClass {
#else
    class UtilityClass {
#endif

    public:
    ...

Now everything compile and run fine, but does not seem a good approach...

Make sure the linker flag `-DMYCLASS_LIBRARY` is not set for more than one project. — AndyG, Oct 02 '15 at 15:13
The application project doesn't define it at all, it's just defined in the library preprocessor macros — ABCplus, Oct 02 '15 at 15:16
Do you define any subclasses/structs or use static variables in the cpp definition? Is the cpp/class definition included in the application compilation? — Simon Kraemer, Oct 02 '15 at 15:18
I'm not sure how that definition works, but you could try to instead move the definition of the symbol to happen at compile time. When you compile the utility class into a separate DLL, pass the option `-DMYCLASS_LIBRARY` to the compiler. Otherwise omit it. In that case, your `global.h` file can remain as it was. Hopefully `global.h` is not actually global, but being used for your utility dll. In a regular project you'd have a "global.h" defining your `__declspec`s for each project producing a DLL. — AndyG, Oct 02 '15 at 15:20
@SimonKraemer : no, the cpp definition does not make use of subclasses/structs/static variables, it's very simple. The cpp class definition is included in the compilation — ABCplus, Oct 02 '15 at 15:22
That might be the problem. The definition is duplicated (once in the lib and once in the app). Could you try to exclude the cpp from the build? — Simon Kraemer, Oct 02 '15 at 15:27
Just found this: http://stackoverflow.com/questions/19926736/inconsistent-dll-linkage-definition-of-dllimport-static-data-member-not-allowe — Simon Kraemer, Oct 02 '15 at 15:28

R Sahu · Accepted Answer · 2015-10-02T15:26:32.770

0

I can think of the following option:

In the desktop application, define a macro, MYCLASS_STATIC and change the .h file to use:

#ifdef MYCLASS_STATIC
  # define MYCLASS_EXPORT 
#elif defined(MYCLASS_LIBRARY)
  # define MYCLASS_EXPORT __declspec(dllexport)
#else
  # define MYCLASS_EXPORT __declspec(dllimport)
#endif

edited Oct 02 '15 at 15:26

answered Oct 02 '15 at 15:22

R Sahu

204,454
14
159
270

Did you mean "library application" instead of "desktop application" for point 1? – ABCplus Oct 02 '15 at 15:24

How to declare a class shared between a library and an application

1 Answers1