I\'m getting an error in my C++ code that I can\'t quite make sense of. The stripped down code bits are here:
RS232Handle=OpenRS232(\"COM1\", 9600);
HANDLE
const char*
and const wchar_t*
are two different types with no implicit conversion between them. Therefore, you need to perform the conversion to before passing the value on to the CreateFile
function. Take a look at this answer for a possible conversion approach: https://stackoverflow.com/a/3074785/6710751
Alternatively you might just use the CreateFileA
function instead of CreateFile
, as was suggested by Ben Voigt.
The Windows CreateFile function is actually a macro that expands to one of:
CreateFileA
, which takes a file path of type const char*
CreateFileW
, which takes a file path of type const wchar_t*
.(The same is true for most of the functions in the Windows API that take a string.)
You're declaring the parameter const char* ComName
, but apparently compiling with UNICODE
defined, so it's calling the W
version of the function. There's no automatic conversion from const wchar_t*
to const char*
, hence the error.
Your options are to:
const wchar_t*
) string.char*
parameter, but have your function explicitly convert it to a UTF-16 string with a function like MultiByteToWideChar.CreateFileA
instead of CreateFile
.UNICODE
, so that the macros expand to the A
versions by default.Edit: I don't know if a kidnapping was involved, but Windows 10 1903 finally added support for UTF-8 as an ANSI code page.
Try this:
RS232Handle=OpenRS232(L"COM1", 9600);
HANDLE OpenRS232(const wchar_t* ComName, DWORD BaudRate)
{
ComHandle=CreateFileW(ComName, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
}
On Windows the wchar_t type is used to represent characters in UTF-16 encoding. This is what the Windows kernel uses internally and therefore modern versions of Visual C++ default to Unicode functions. If you insist on using the ANSI functions instead (thus going back to your original code), remove the L
-prefix from the string "COM1" and change the call from CreateFileW
to CreateFileA
.
Most Windows API functions that deal with strings have both a W
and an A
version; the only exception that I am aware of is the function GetProcAddress which always takes an ANSI string regardless of whether you're working with ANSI or Unicode in your project.
There are many ways of fixing this
Note that in some error handling routine the strings are specifically MBCS