Standard C++ doesn't compile in Qt Creator

Question

I'm using the MingW32 G++ compiler in the Qt Creator at the moment.

I've ported over working code from CodeBlocks into Qt so I can use Qt's networking features, but the moment I port over the code, it fails to compile with the errors of:

C:\software\Qt\AutoUpload\main.cpp:90: error: cannot convert 'std::__cxx11::string {aka std::__cxx11::basic_string<char>}' to 'LPCWSTR {aka const wchar_t*}' for argument '1' to 'void* FindFirstFileW(LPCWSTR, LPWIN32_FIND_DATAW)'
 HANDLE handle = FindFirstFile(dir, &search_data);

The piece of code that gives this error is line 8:

1 vector<string> getFilesInDir(string directory)
2 {
3     vector<string> filenames;
4     string dir = string(directory + "\\*");
5 
6     WIN32_FIND_DATA search_data;
7     memset(&search_data, 0, sizeof(WIN32_FIND_DATA));
8     HANDLE handle = FindFirstFile(dir.c_str(), &search_data);
9     while (handle != INVALID_HANDLE_VALUE)
10    {
11        if (FindNextFile(handle, &search_data) == FALSE) break;
12        if (search_data.cFileName == string(".") || search_data.cFileName == string(".."))
13        {
14            cout << "Ignoring..." << endl;
15            continue;
16        }
17        filenames.push_back(search_data.cFileName);
18        cout << search_data.cFileName << endl;
19    }
20
21    FindClose(handle);
22    return filenames;
23 }

Other questions such as ones found here and here state that this is some issue with Unicode encoding that the Windows API uses with the LPCWSTR type, but this answer is either incomplete or incorrect. My encoding settings with both CodeBlocks and Qt Creator are UTF-8 and not Unicode or any other encoding method.

If this were a Unicode issue, this code would not have compiled in Visual Studio or CodeBlocks, but it is regardless. The ONLY environment it doesn't compile perfectly fine is in Qt.

What is Qt Creator doing that is suddenly making this code non-functional?

See the second answer. http://stackoverflow.com/questions/8032080/how-to-convert-char-to-wchar-t — Shakil Ahamed, Mar 02 '17 at 17:44
Yes it does. I manually added the line numbers in the example so I could easily point out the line in which the error is occuring. (line 8 according to the snippet. Line 90 in the full code base) Maybe you should actually read the question before commenting. — Kats, Mar 02 '17 at 17:44
I mean that in the error message you pass a `std::string` object (`dir`) as the first argument, but in the code you use `dir.c_str()`. While using `dir.c_str()` *may* give you an error, it will not be the same error you're asking about. Also, please don't add line numbers, instead add a *comment* on the line the error(s) are. — Some programmer dude, Mar 02 '17 at 17:47
```dir.c_str()``` is exactly how it compiles in CodeBlocks. I use ```strings``` by default. That's just my work flow. There's no real point not to unless you're writing something that has to be super efficient. — Kats, Mar 02 '17 at 17:52
The error message you get does not come about when you compile the code in this question! The message itself contains the erroneous code, and as should be obvious it simply doesn't match the code you present. As such, this question is misleading. Please edit it to post the *actual* error message. — Kuba hasn't forgotten Monica, Mar 02 '17 at 18:51
Your code is incomplete; in particular, it seems to be missing a `main()` function and at least one `#include`. Please [edit] your code so it's a [mcve] of your problem, then we can try to reproduce and solve it. You should also read [ask]. — Toby Speight, Mar 03 '17 at 14:30

score 3 · Accepted Answer · answered Mar 02 '17 at 17:46

3

All functions taking strings in the Windows API are actually macros.

If you look at the bottom of this FindFirstFile reference you will see that there are two functions, FindFirstFileW and FindFirstFileA. Which one is used depends on on the UNICODE macro, if it's not defined the ANSI function (FindFirstFileA) is used, otherwise the wide character version (FindFirstFileW) is used.

If UNICODE is defined you need to use wide-character versions of e.g. the string class, which is std::wstring.

answered Mar 02 '17 at 17:46

Some programmer dude

400,186
35
402
621

So my solution is literally to just add ```#undef UNICODE``` to the top of the file? This is a much more helpful answer than whatever roundabout solution every other question was trying to answer with. – Kats Mar 02 '17 at 17:50
@Kats It really depends on the rest of your code. And the `UNICODE` macro is controlled by a flag in the project settings (I don't really know exactly where though). – Some programmer dude Mar 02 '17 at 17:54
Adding ```#undef UNICODE``` does work and allows the code to compile and run as intended. Why is this a necessary step in Qt Creator when every other IDE doesn't mandate it? – Kats Mar 02 '17 at 17:56
@Kats It's probably to make Qt Creator compatible with Visual Studio and the VC++ compiler. This is in fact a major headache with programming for the Windows API, making it not portable even on the same platform. – Some programmer dude Mar 02 '17 at 17:58
You would think if that were the case that Qt would default to the VC++ compiler rather than MingW. – Kats Mar 02 '17 at 17:59
1

@Kats CodeBlocks had set up the build to default to narrow strings - that's not MingW's doing, and nothing to do with Qt. All modern Windows code has UNICODE defined. Your code was broken to begin with since you've designed it with the assumption that UNICODE is not defined. CodeBlocks was essentially misleading you about how to write portable modern WINAPI-using code. It was the outlier. When you assume that UNICODE is defined, your code will cleanly compile using default settings in native Visual Studio project, in a qmake project, and in cmake project. – Kuba hasn't forgotten Monica Mar 02 '17 at 18:53
I didn't design it to assume anything. That's a problem with Windows for assuming that every developer will use UNICODE by default. That's Windows' fault for interjecting code into programs when it's not asked for. That's the problem with the Windows environment. It's not me as a programmer, it's Windows for always trying to change things and breaking everything it touches. – Kats Mar 03 '17 at 15:11
@Kats: You are getting the timber to burn yourself. At this point there is no reason to not do things the Unicode way. You are driving the car for the wrong sense. – sergiol Jul 22 '17 at 23:20

Standard C++ doesn't compile in Qt Creator

1 Answers1