I'm writing a C program using the Windows API. Each major function has its own file, and there is one header for the prototypes and includes and whatnot:
// Headers & global constants
#pragma once
#define _WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <WindowsX.h>
#include <Windef.h>
#define szClassName TEXT("EthicsPresentationWnd")
// Prototypes
LRESULT CALLBACK WindowProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam);
BOOL CALLBACK FontProc1(HWND hWnd, LPARAM lParam);
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd);
ATOM RegisterWindow(HINSTANCE hInstance);
The thing I'm irritated about is the #define szClassName line. I dislike using macros and would prefer to have a proper global variable, wchar_t szClassName[], but if I do that then the linker complains about multiply defined variables in each of the modules that include the header.
I thought the #pragma once directive would prevent this, but it didn't.
Is there any solution to this problem?
The solution to this is to have a separate declaration and definition...
Header (*.h; sorry, I don't know WinAPI type names, adapt as necessary):
extern const char szClassName[];
Implementation (*.c or *.cpp)
const char szClassName[] = "hello, world"
You're seeing the problem because a new symbol szClassName is being declared each time one of your *.c or *.cpp files includes the header (even with the include guards!); and that makes the linker confused (see below).
Do note that this will make sizeof(szClassName) not work anymore.
After preprocessing, the compiler is basically seeing this:
const char someSymbol[] = <some text, don't care what right now>;const char someSymbol[] = <some text, don't care if it's the same>;const char someSymbol[] = <some text, ditto>;When the linker is linking the object files (say, "a.obj", "b.obj" and "c.obj"), it sees the same symbol being defined with a new value (at least as far as the linker is concerned) --- and thus it fails with an error.