c - _setmode function causing debug error - c

Question

Ok, so after posting this question I tried to use the solutions provided in the related questions (particularly this) pointed by the community but I had another problem.
When trying to use the _setmode() function to change the Windows console to print UTF characters I get a debug error, just like the one posted on this other question. The debug error is as follows:
Text:
Debug Assertion Failed!
Program:
...kout-Desktop_Qt_5_5_0_MSVC2013_64bit-Debug\debug\Breakout.exe
File: f:\dd\vctools\crt\crtw32\stdio\output.c
Line: 1033
Expression: ((_Stream->_flag & _IOSTRG) || ( fn = _fileno(_Stream), (
(_textmode_safe(fn) == _IOINFO_TM_ANSI) &&
!_tm_unicode_safe(fn))))
For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.
(Press Retry to debug the application)
Screenshot:
Without the _setmode() function I still can't print characters from the upper ASCII Table, like these: "┌──┐". What can I do to solve this problem? The solution to the question with the same problem doesn't work also.
Again, I'm using Qt Creator on Windows, with Qt version 5.5.0 MSVC 64 bits. The compiler is the Microsoft Visual C++ Compiler 12.0 (amd64).
Edit:
Here's a small sample code that causes the error:
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
int main(void)
{
//Using setmode to force the error
_setmode(_fileno(stdout), _O_U16TEXT);
printf("Hello World!\n");
return 0;
}
Upon execution the error appears.

Answer 1

It seems that if you set the output mode to UTF-16, you must then use wprintf instead of printf.
(Presumably, since you have told the runtime to translate from UTF-16, you have to provide UTF-16.)
This code runs on my machine:
#include <fcntl.h>
#include <io.h>
#include <stdio.h>
int main(void) {
_setmode(_fileno(stdout), _O_U16TEXT);
wprintf(L"\x043a\x043e\x0448\x043a\x0430 \x65e5\x672c\x56fd\n");
return 0;
}
So does
wprintf(L"Hello world!\n");
PS - I'm not sure whether this will solve your underlying problem, which I suspect has to do with the encoding of the source file. Even if using UTF-16 does solve your problem, it probably isn't the best solution.