SOCI / soci

Official repository of the SOCI - The C++ Database Access Library
http://soci.sourceforge.net/
Boost Software License 1.0
1.37k stars 472 forks source link

SOCI doesn't compile when using the `UNICODE` flag on Windows #1111

Open Krzmbrzl opened 6 months ago

Krzmbrzl commented 6 months ago

When defining the UNICODE preprocessor flag when compiling on Windows, SOCI fails to compile. The reason being that this flag causes functions calls to the Windows API that don't explicitly use the A (Ansi) or W (wide-string, aka: "unicode") flavor to switch to the latter and SOCI seems to expect to use the former.

I guess the easiest fix would be to simply be explicit about using the A variants of functions such as LoadLibrary (LoadLibraryA).

However, this wouldn't account for everything as e.g. ODBC seems to also take this setting into account causing it to use SQLWCHAR instead of SQLCHAR which then causes further compile errors. Maybe explicitly un-defining UNICODE in the affected source files might be enough to revert back to normal behavior?

Another option would be to make SOCI itself adapt this "unicode"-weirdness (on Windows) and switch to wide-charracter representations. However, I think this is probably the least desirable way forward :eyes:

vadz commented 6 months ago

Why do you need to compile SOCI itself with UNICODE defined? Note that you can compile the application including SOCI headers with it being define just fine, of course.

Krzmbrzl commented 6 months ago

I tried undefining UNICODE for the SOCI part but got redefinition errors of some Windows API functions - I'm using static linkage. Maybe I need only refine my approach to make things work though 👀

In any case I was wondering whether it would make sense for SOCI to deal with this somehow - even if it is only a check whether this macro is defined and emitting an error stating that compiling SOCI with UNICODE is not supported. That'd already make things easier for downstream users as they don't have to wonder where that compile error is coming from.

vadz commented 6 months ago

FWIW I agree that the simplest fix would be to use A variants of all A/W functions and hope that everybody uses UTF-8, which should work on all non-ancient Windows systems.

bold84 commented 3 months ago

https://github.com/SOCI/soci/pull/1041

This should solve the problem.