Using the #define macro to standardize class declaration - c++

I'm building a C++ DLL for one of my projects. I am trying to standardize the way that are class are defined. So instead of each time writing:
class __declspec(dllexport) ClassName
I'm building a #define macro to ease this process:
#define CLASS( cName ) class __declspec(dllexport) cName
But, when I'm using it, it gives me the following error:
Error: Expected a ';'
I know you can use a #define macro to define an entire class creation, but can it be used to define only the "class header" ?
Thanks,
Keep in mind that I'm trying to do so because we are going to deal with hundreds of classes, so these kinds of "automation" would be most helpful :)
EDIT:
example:
#define CLASS( nClass ) class __declspec(dllexport) nClass
CLASS( APTest )
{ // Here is the error of missing ';'
public:
APTest();
};

Don't do this.
C++ has already been standardized!
If you ever expect other people to read your code then just write it in conventional C++, not some homecooked dialect that looks different. Get used to the proper C++ syntax, it will make it easier to read other people's C++ code.
One thing that does make sense is to simplify the __declspec part, which you can do like this:
#ifdef _WIN32
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT
#endif
class DLLEXPORT APTest
{
// ...
};
You're really not making your life any simpler by writing CLASS( APTest ) and you make it harder for others to understand. Just say no.

There is a better way than #Wakely. Do it like this:
#ifdef MYLIB_DLL
#ifndef MYLIB_IFACE
#ifdef MYLIB_IFACE_EXPORT
#define MYLIB_IFACE _declspec( dllexport )
#else // !MYLIB_IFACE_EXPORT
#define MYLIB_IFACE _declspec( dllimport )
#endif // !MYLIB_IFACE_EXPORT
#endif // !MYLIB_IFACE
#else // !MYLIB_DLL
#ifndef MYLIB_IFACE
#define MYLIB_IFACE
#endif // !MYLIB_IFACE
Put a block like that in a header that is used by every file in your dll, and in the public header for your dll.
Every symbol that should be exported from your dll gets tagged like this:
class MYLIB_IFACE MyClass
{
};
void MYLIB_IFACE myFunc();
Then in every .cpp file in your dll the first line should be:
#define MYLIB_IFACE_EXPORT
If you do this, then it will build just fine on POSIX systems that don't use dllexport/dllimport. To build a dll version of your lib you define MYLIB_DLL. ( you can do this in the compiler's flags so it can be controlled from your build system )
To build a static version of your lib, don't define MYLIB_DLL.
#Update:
You can extend this to support GCC visilibity like this:
#ifdef WIN32
#define KX_SYMBOL_EXPORT _declspec( dllexport )
#define KX_SYMBOL_IMPORT _declspec( dllimport )
#else // GCC
#define KX_SYMBOL_EXPORT __attribute__(( visibility ("default")))
#define KX_SYMBOL_IMPORT
#endif
#ifdef KX_DLL
#ifndef KX_IFACE
#ifdef KX_IFACE_EXPORT
#define KX_IFACE KX_SYMBOL_EXPORT
#else // !KX_IFACE_EXPORT
#define KX_IFACE KX_SYMBOL_IMPORT
#endif // !KX_IFACE_EXPORT
#endif // !KX_IFACE
#else // !KX_DLL
#ifndef KX_IFACE
#define KX_IFACE
#endif // !KX_IFACE
#endif // !KX_DLL
I remove the GCC bit in the first example for simplicity. But this is how a really do it. #Wakely is so right.

Related

How to initialize api function pointers from a dynamic library in a C-API

I'm explicitly loading a c-API dynamic library (dll/so), where it is not possible to link symbols with a lib-file. So I use GetProcAddress and dlsym to find the apropriate functions.
The problem I have is due to the static declaration of "foo" and "baz" I have to use GetProcAddress/dlsym for every implementation file that includes this header.
The behaviour I want is that I only want to lookup the symbols once for the process.
Do I have to declare them all as "extern" then have a own set of function pointers in the project that I then set with GetProcAddress/dlsym?
What is the recommended way to fix it?
Example API header:
#ifdef _WIN32
#define API_IMPORT __declspec(dllimport)
#define API_EXPORT __declspec(dllexport)
#elif defined(__GNUC__)
#define API_EXPORT __attribute__((visibility("default")))
#define API_IMPORT
#else
#error Unsupported for now
#endif
#if LIB_COMPILING
#define API_DECL API_EXPORT
#else
#define API_DECL API_IMPORT
#endif
#ifdef __cplusplus
extern "C" {
#endif
API_DECL int ifoo(int bar);
API_DECL void ibaz(int qux);
typedef int (* PFN_FOO_PROC)(int);
typedef void (* PFN_BAZ_PROC)(int);
static PFN_FOO_PROC foo = 0;
static PFN_BAZ_PROC baz = 0;
#ifdef __cplusplus
}
#endif
"ifoo" and "ibaz" contains the actual implemenations in a c-file for the dynamic library.
So in this example to load symbols for linux:
foo = (PFN_FOO_PROC) dlsym(handle, "ifoo");
baz = (PFN_BAZ_PROC) dlsym(handle, "ibaz");
Thanks for any help
The whole idea behind delay loading is that you don't have to use LoadLibrary / GetProcAddress. Instead, if (say) foo is a function in your delay loaded DLL you can simply say if (foo) before calling it to see if it's actually available.
I know less about Linux and macOS, but I do know that macOS has 'weak linking' which operates in a similar way. I don't know what Linux does, sorry, but I imagine it offers something similar.

Using __declspec( dllexport )

Hi I'm little bit confused with dllexport.When I use __declspec( dllexport ) for example in class
#define DllExport __declspec( dllexport )
class DllExport C {
int i;
virtual int func( void ) { return 1; }
};
do I export class C to dll file or do I export C class from dll file?
When compiling the DLL you have to write __declspec(dllexport) as you did. This tells the compiler you want it to be exported. When using the DLL you want __declspec(dllimport) in your included files. The compiler then knows that this functions and classes are in a DLL-file and need to be imported. Because you don't want to change your header-files that much, you should define a macro e.g. BUILD_DLL.
#ifdef BUILD_DLL
#define DLL_PORTING __declspec(dllexport)
#else
#define DLL_PORTING __declspec(dllimport)
#endif
Now you write in example.h:
class DLL_PORTING example_class { … };
In your .exe file just include the header files you need and everything will work.

Using __declspec(dllimport) in a class containing a static member of its own type

I have a class which header looks like this:
class MYCLASS_DECLSPEC MyClass
{
MyClass(int x);
....
static const MyClass Zero;
}
On the implementation file I initialized the static const member:
const A A::Zero(0);
Now I want to compile this code sometimes as a DLL and sometimes as static library. The common practice is to define MYCLASS_DECLSPEC like this:
#ifdef BUILDING_MYDLL
#define MYCLASS_DECLSPEC __declspec(dllexport)
#else
#define MYCLASS_DECLSPEC __declspec(dllimport)
#endif
When I compile this code as DLL (with BUILDING_MYDLL defined) everything is working fine. But when I compile this code as static library (without BUILDING_MYDLL defined) I get the following error:
error: definition of static data member 'MyClass::Zero' of dllimport'd class
If I totally remove the __declspec(dllimport) the code compiles successfully as a static library.
I'm using mingw32 compiler on Windows 7.
Can someone explain why it happens and how to solve it?
I would think we put #defines in another #define:
#ifdef _DLL
#ifdef BUILDING_MYDLL
#define MYCLASS_DECLSPEC __declspec(dllexport)
#else
#define MYCLASS_DECLSPEC __declspec(dllimport)
#endif
#else
#define MYCLASS_DECLSPEC
#endif

Including header files from libraries when building a new library

To be clear:
I'm aware that the below example demonstrates a dll-dependancy, i.e. one library is not self-containe, but depends on another library to function.
Let's say I'm creating a runtime library, Utility.dll, which contains various useful functions of general nature.
I create a header file Utility.h to be included in other files which need to use Utility.dll.
The header file looks like
#ifndef _UTILITY_H
#define _UTILITY_H
#ifdef BUILD_DLL
#define DLL_EXPORT __declspec(dllexport)
#else
#define DLL_EXPORT __declspec(dllimport)
#endif
DLL_EXPORT void foo();
DLL_EXPORT void foo2();
....
#endif
When I compile the source code file Utility.cpp into machine code (into Utility.dll) I make sure BUILD_DLL is defined so DLL_EXPORT gets replaced with __declspec(dllexport). This makes the functions be exported to the .dll file.
Whenever I include the header Utility.h and link with the import library (Utility.lib for MS VS, libUtility.a for g++) and do not define BUILD_DLL, the function declarations in Utility.h begin with __declspec(dllimport) instead, telling the compiler that the functions are imported from a .dll (so to speak).
Now, let's say I'm also building another library, MyLibrary.dll, which wants to use some of the useful functions in Utility.dll. Similarily, I would create MyLibrary.h as
#ifndef _MYLIBRARY_H
#define _MYLIBRARY_H
#ifdef BUILD_DLL
#define DLL_EXPORT __declspec(dllexport)
#else
#define DLL_EXPORT __declspec(dllimport)
#endif
DLL_EXPORT void myLibraryFunc1();
....
#endif
When I compile MyLibrary.cpp into MyLibrary.dll I'm including Utility.h and also linking against the Utility import library.
This leads us to my question:
Since I define BUILD_DLL also when I compile MyLibrary.dll, this means that the function declarations in Utility.h also will read
__declspec(dllexport) void foo();
__declspec(dllexport) void foo2();
....
Not
__declspec(dllimport) void foo();
__declspec(dllimport) void foo2();
Don't we want it to be __declspec(dllimport) for the function declarations in Utility.h when we compile MyLibrary.dll, and __declspec(dllexport) for the function declarations in MyLibrary.h?
This is precisely the reason why you normally don't name such macros BUILD_DLL, but BUILD_UTILITY and BUILD_MYLIBRARY or similar. Likewise, the declspec macro should not be DLL_EXPORT, but UTILITY_EXPORT and MYLIBRARY_EXPORT (or perhaps UTILITY_API and MYLIBRARY_API).

Conditional preprocessing puzzle

I have a problem where I can't seem to get conditional #define preprocessors to work correctly. For example:
#define WIN32_BUILD
#ifdef WIN32_BUILD
#define PCH "stdafx.h"
#else
#define PCH "xyz.h"
#endif
#include PCH
If I use this form, the compiler tells me that it can't find 'stdafx.h'. OK, that seems odd, so if I change the code to....
#define WIN32_BUILD
#ifdef WIN32_BUILD
#define PCH "xyz.h"
#else
#define PCH "stdafx.h"
#endif
#include PCH
Then the file defined in PCH gets picked up and everything compiles fine. This seems odd to me, almost like the preprocessor is ignoring the #if directives and just using all the #defines that it encounters.
Obviously I am doing something wrong, and I was hoping that someone could help me understand this.
When a project has the precompiled header feature turned on the preprocessor ignores everything that comes before #include "stdafx.h"
So your #define statements are ignored.
TL:DR; #define defines the symbol, #ifdef tests if the symbol is defined not whether it has a value.
#define WIN32_BUILD
This defines a pre-processor token, WIN32_BUILD. The token has no value. Anywhere you use the token 'WIN32_BUILD' the pre-processor will substitute the empty string, i.e. nothing.
#ifdef WIN32_BUILD
This checks if the pre-processor token WIN32_BUILD is defined. It is, you just defined it.
#ifdef WIN32_BUILD
// true - this code is included.
#define PCH "stdafx.h"
This defines the pre-processor token, PCH, and assigns it the value "stdafx.h"
#else
#define PCH "xyz.h"
#endif
This code is ignored, because WIN32_BUILD was defined.
It looks as though you were expecting 'ifdef' to only evaluate to true if the expression was not defined /to/ something.
#define a
#define b SOMETHING
#ifdef a
// you are expecting this to be ignored
#endif
#ifdef b
// and expecting this not to be ignored
#endif
#ifdef and #if defined(...) do the same thing.
#define a
#define b SOMETHING
#if defined(a) && defined(b)
// this code will be evaluated, both tokens are defined.
#endif
This feature of pre-processor tokens is often used to support conditional functionality:
#if HAVE_CPP11_OVERRIDE_KEYWORD
#define OVERRIDE_FN override
#else
#define OVERRIDE_FN
#endif
struct A {
virtual void foo() {}
};
struct B : public A {
void foo() OVERRIDE_FN {}
};
In the above code, the override keyword is only added if the system supports it (determined outside of the code).
So a compiler with override sees
struct B : public A {
void foo() override {}
};
a compiler without it sees
struct B : public A {
void foo() {}
};
Note: The opposite of "ifdef" is "ifndef":
#define a
#define b SOMETHING
#undef c
//#define d // << we didn't define it.
int main() {
#ifdef a
#pramga message("a is defined")
#else
#pramga message("a is UNdefined")
#endif
#ifdef b
#pragma message("b is defined")
#else
#pramga message("b is UNdefined")
#endif
#ifdef c
#pramga message("c is defined")
#endif
#else
#pramga message("c is UNdefined")
#endif
#ifdef d
#pramga message("d is defined")
#endif
#else
#pramga message("d is UNdefined")
#endif
#ifndef d
#pragma message("d is not defined")
#endif
#ifndef a
#pragma message("a is not defined")
#endif
return 0;
}
You can assign a pre-processor token numeric values and test them with #if
#if _MSC_VER
#define WIN32_BUILD 1
#else
#define WIN32_BUILD 0
#endif
#if WIN32_BUILD
#include <Windows.h>
#endif
But, especially when doing cross-platform programming, people tend to use ifdef variants rather than numeric checks, because the value checks require you to explicitly ensure all of the tokens are defined with a value. It's a lot easier just to only define them when you need them.