0

I bought a Surface Go 2 today, and installed Visual Studio 2019. I loaded my project, that successfully compiled on my previous PC, also in VS19.

The first problem that I noticed is that the VS editor displays Unicode characters (Cyrillic) in my .cpp files as hieroglyphs:

card->NewTextW(L"Çàãðóçêà", ...

Instead of:

card->NewTextW(L"Загрузка",

Then I tried to compile the project, but got more then a hundred errors, and all of them were about the compiler can't convert from const wchar/char * to wchar/char *, although, I repeat, that earlier, in another PC, everything compiled successfully. This error appears to almost all types of strings, and for strings with wrong encoding, like mentioned above, and without.

Specific example of error

card->NewTextW(L"Çàãðóçêà", 3, r.right/2-50, r.bottom / 2 - 350 / 2 - 80 + 350 + 60, 10, 20, RGB(0, 0, 0));
card->NewText("eng-string", 4, r.right/2-50, r.bottom / 2 - 350 / 2 - 80 + 350 + 60, 10, 20, RGB(0, 0, 0));

Where card is a pointer to an object of interface virtual class ICard:

class ICard
{
public:
...
virtual void NewTextW(wchar_t *text, int id, int x, int y, int divid, int j, COLORREF col) = 0;
virtual void NewText(char *text, int id, int x, int y, int divid, int j, COLORREF col) = 0;
...
}card*;

Specific example of no error

MessageBoxA(NULL, "aga", "uogou", MB_OK);
Thawbkisavv
  • 17
  • 5
  • You seem to be coupling two different problems in this question. One part is the string literals being passed to non-`const` character pointers which is actually illegal in C++, and always has been (if this worked before, it must have had some extension or compatibility enabled in the setup). The other part is the unicode characters, which could be a number of entirely unrelated problems. Please ask only one thing per question as it makes it easier to answer – Human-Compiler Apr 07 '21 at 17:37
  • @Human-Compiler I understand that it rather different problems, but, perhaps they are related, so I gave more details, including the issue with encoding. – Thawbkisavv Apr 07 '21 at 17:39
  • @Human-Compiler as for always existing illegality and "extension or compatibly" You mentioned, it is a bit surprising for me, because the interface class I mentioned in the post, I wrote about 6 years ago, and since that time have changed Visual Studios a lot of times, and have never faced that issue – Thawbkisavv Apr 07 '21 at 17:44
  • @Human-Compiler, however adding `const` in methods argument list solves my problem. – Thawbkisavv Apr 07 '21 at 17:55
  • @Human-Compiler "*which is actually illegal in C++, and always has been*" - not always, only since C++11. Earlier versions of C++ allowed string literals to be assigned to non-const pointers, for backwards compatibility with C. C++11 onwards forbid it now. In VS2019, you can enable the `/permissive` option, or enable the `/Zc:strictStrings-` option, to re-enable the old behavior – Remy Lebeau Apr 07 '21 at 19:33
  • @RemyLebeau Wait, really? I always thought the string to `char*` was an extension by the compiler for compatibility with C -- but wasn't actually part of the standard. – Human-Compiler Apr 07 '21 at 19:53
  • 1
    @Human-Compiler it was in the C++03 standard, at least: "*§4.2/2 (conv.array/2) A string literal (2.13.4) that is not a wide string literal can be converted to an rvalue of type “pointer to char”; a wide string literal can be converted to an rvalue of type “pointer to wchar_t”. In either case, the result is a pointer to the first element of the array. This conversion is considered only when there is an explicit appropriate pointer target type, and not when there is a general need to convert from an lvalue to an rvalue. [Note: this conversion is deprecated. See Annex D. ]*" – Remy Lebeau Apr 07 '21 at 21:21
  • @RemyLebeau TIL -- thank you for correcting me on that! That quote also explains why I was sure I had at least seen compiler warnings on this conversion long before C++11, which can be explained by the footnote of "this conversion is deprecated". – Human-Compiler Apr 07 '21 at 21:27
  • @Human-Compiler C++98 expands on that wording with an example (maybe C++03 did too, I don't know - I don't have the actual standards to look at): "*... For the purpose of ranking in overload resolution (13.3.3.1.1), this conversion is considered an array-to-pointer conversion followed by a qualification conversion (4.4). [Example:"abc" is converted to “pointer to const char” as an array-to-pointer conversion, and then to “pointer to char” as a qualification conversion. ]*" – Remy Lebeau Apr 07 '21 at 21:32

2 Answers2

1

Cannot covert from 'const char*' to 'char*' in VS19, although earlier version could

According to the doc: /permissive- (Standards conformance)

By default, the /permissive- option is set in new projects created by Visual Studio 2017 version 15.5 and later versions. It's not set by default in earlier versions. When the option is set, the compiler generates diagnostic errors or warnings when non-standard language constructs are detected in your code. These constructs include some common bugs in pre-C++11 code.

As far as I'm concerned, this is a good explanation of why this error did not appear in the earlier version.

Nimantha
  • 6,405
  • 6
  • 28
  • 69
Jeaninez - MSFT
  • 3,210
  • 1
  • 5
  • 20
-1

It seems like the code is working as is for me on godbolt.org

https://godbolt.org/z/nGz3hcG3c

Not needing to change parameters to const or anything else...

I do get warnings using gcc but not msvc

This looks like a compiler issue on your end, not with msvc19 I wonder if your VS install has a setting that treats warnings as errors? Check out https://stackoverflow.com/a/66485736/496405 to disable this option.

g19fanatic
  • 10,567
  • 6
  • 33
  • 63
  • The error is warranted since C++11, and msvc [will (correctly) issue it](https://godbolt.org/z/nsWdsqsje) in `/permissive-` conforming mode. – dxiv Apr 07 '21 at 23:43