11 minutes ago, Bregma said:
It may work for you. It may not, because you need to specify some special linkage option
I know and this is a good point of "learn to know your APIs". You need to know the signature and history of whatever you are using. So in my case anything I use are legacy functions in Windows and core features in Linux/ Android for example. LoadLibraryW, CreateThread, OpenFileW are examples of those legacy code that I doubt will ever change in upcomming Windows (10) versions because this is the barebone code of kernel32.dll the whole OS depends on. I totally agree for newer functions but I don't intended to use one yet and it seems that it won't be necessary to do so.
The other point is true, there are still old FAR declarations in the header files as same as special MACOS sections but they seem and my research confirmed that they aren't used anymore and I don't intend to support Systems older than Windows XP, maybe even Windows 7 as lowest supported OS. There those macros are defined to void.
But what I especially like about doing that is (except for linking against kernel32 that is a default dependency in Visual Studio) that the code keeps clean, my namespaces are pretty small and compile times as same as my own analyzer tools run a lot less when not in need to parse the mess of windows.h and it's included header files.
#define SE_WINAPI stdcall
#include <Windows/DataTypes.h> //<-- defines the common WINAPI types WORD, DWORD ...
//#define static_link extern "C"
namespace Runtime
{
typedef FILETIME* LPFILETIME;
static_link dll_import BOOL SE_WINAPI QueryPerformanceCounter(LARGE_INTEGER *lpPerformanceCount);
static_link dll_import BOOL SE_WINAPI QueryPerformanceFrequency(LARGE_INTEGER *lpFrequency);
static_link dll_import void SE_WINAPI GetSystemTimeAsFileTime(LPFILETIME lpSystemTimeAsFileTime);
}
force_inline int64 SE::System::GetHighResolutionTime()
{
Runtime::LARGE_INTEGER result;
Runtime::QueryPerformanceCounter(&result);
return static_cast<int64>(result.QuadPart);
}
force_inline int64 SE::System::GetClockFrequency()
{
Runtime::LARGE_INTEGER result;
Runtime::QueryPerformanceFrequency(&result);
return static_cast<int64>(result.QuadPart);
}
force_inline uint64 SE::System::GetTimestamp()
{
Runtime::FILETIME result;
Runtime::GetSystemTimeAsFileTime(&result);
return static_cast<uint64>(result.dwHighDateTime) << 32 | result.dwLowDateTime;
}
#undef SE_WINAPI
(Taken from my GitHub)
The only point I needed to use the windows.h header file was for the MemoryBarrier function macro using atomic variable access but I put that into a .cpp file to hide it behind a function also and excluded as many windows.h features as possible.
My design is to have the Runtime namespace to contain any platform/ hardware dependent API call and hide this behind the System namespace that unifies access to these calls. A programer can then either use the System namespace driectly or have the wrapper classes like File or Thread do that for him and he just uses those classes.
This feels like the design I can best work with