Preprocessor makes function name unaccessabel - sqlite

Question

I have to create a SQLite database using System.Data.SQLite and using C++/CLI but I run into problems. Unfortunately, using C# is not an option, if it was then there is no problem. (Please don't advise me not to use C++/CLI, it is not an option in this project.)
In C# the following code works without any problem.
using System.Data.SQLite;
void CreateDb(String file)
{
SQLiteConnection.CreateFile(file);
}
The equivalent code in C++/CLI is not without its problems.
using namespace System::Data::SQLite;
void CreateDb(System::String ^file)
{
SQLiteConnection::CreateFile(file); // error C2039
}
The exact error txt for C2039 is:
// error C2039: 'CreateFileA' : is not a member of 'System::Data::SQLite::SQLiteConnection'
If I take a closer look at the definition of CreateFile I get the following choice
#define CreateFile CreateFileW - c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\WinBase.h(9292)
#define CreateFile CreateFileA - c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\WinBase.h(9294)
Which leads to the following lines in WinBase.h
#ifdef UNICODE
#define CreateFile CreateFileW
#else
#define CreateFile CreateFileA
#endif // !UNICODE
The Microsoft SDK is muddling with exact the name that I need and SQLite does not provide me with CreateFile[AW] versions.
So I tried this before the code calling SQLiteConnection.CreateFile(file) and I do this isolated so that other code is affected by it.
#ifdef CreateFile
#undef CreateFile
#endif
It solves my problem (for now) but how safe is this?
Is there a better way of solving this problem?
Your advise is much appreciated.

Answer 1

The #undef is how I've always handled this.
how safe is this?
This is safe.
You may have this problem again if you have other name collisions. The compile errors resulting from such a name collision are easy to diagnose, now that you know what you're looking for, so it will be easy to add additional #undef directives if needed.
If you need to call the Win32 CreateFile, you will need to type CreateFileA or CreateFileW explicitly, but that's not a big hassle.
Is there a better way of solving this problem?
Yes, but it's not always possible.
The better way is to not #include <Windows.h> in the files where you use SQLite. This avoids the problem entirely. However, it's not always possible to organize your program like this, so #undef is usually the solution.
(This next paragraph doesn't apply to your scenario with SQLite: You're using the managed version, so there's no headers. This next bit applies to C++ libraries that include library headers. I'm including it for completeness in case someone is writing plain C++.)
One other thing to watch out for here is #include-ing the Windows headers before library headers. In that case, the class definition itself will have CreateFile renamed to CreateFileA. If you use #undef with that, you'll get the opposite error from what you showed. You can leave the #define in place, which will sometimes end up working, but this is rather fragile, so I would avoid this scenario.
(I ran into this once with MFC headers in a C++ application: The changed method name ended up everywhere, even Intellisense showed the name as ending in "A". It worked anyway because the vTable was initialized inside the MFC DLL, and so all that mattered in the calling application was that the vTable pointed at the right method, which it was.)