Error C2440 Qt Creator not allowing literals to be passed as "char *"

[Sprezzatura]

(Not sure if this should be posted in "General & Desktop"?)

We are converting an app from VS2017 to Qt Creator 4.7.0 (Qt 5.11.1). Qt is a bit more stringent. We are getting error C2440 on this type of code, which compiles and runs fine in VS:

void foo(char *);
foo ("ABC");

Qt Creator is not allowing it, we have to change to:

void foo(const char *);

Yes, I know this is the correct way, and it's good for us. However, the code has been working successfully for years in VS, we have a big job ahead of us, and would just like to move on and work on more difficult stuff.

Can we selectively suppress certain errors? Or tell the compiler to ease up?

[VRonin]

@Sprezzatura said in Error C2440 Qt Creator not allowing literals to be passed as "char *":

Qt is a bit more stringent

Qt is not a compiler

We are getting error C2440 on this type of code, which compiles and runs fine in VS

error C2440 is a MSVC error. Nothing to do with Qt

Can we selectively suppress certain errors? Or tell the compiler to ease up?

https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=vs-2017

[Sprezzatura]

OK, fine. How do I get MSVC to be as lenient, when launched from Qt, as when it runs stand-alone? How do I tell Qt Creator how to pass command line switches to MSVC?

In other words, why am I getting the error when compiling from within Qt Creator, as when compiling directly from MSVC?

[Sprezzatura]

I just noticed your link to "/Zc:strictStrings". Excellent news. Now, I just need to know how to pass this on to MSVC?

[aha_1980]

@Sprezzatura

Try adding QMAKE_CXXFLAGS += /Zc:strictStrings- to your .pro file (assuming you use qmake)

I guess /permissive is set and therefore you explicitely need to disable strictStrings.

Disclaimer: Fix these functions soon, nevertheless. This option is to prevent subtile bugs.

Regards

[Buckwheat]

Hi @Sprezzatura
If you know it is good to use proper C++ then why would you want to suppress warnings. By suppressing warnings globally you can (and probably will) cause a problem at a later time or someone else maintaining the code could cause a problem.

It is ALWAYS the best practice to use the highest warning levels and just write clean code. So, in conclusion, it is better to take a small amount of time fixing unsafe code than masking other issues by disabling warnings. If this is a group responsibility, bring it up to the group and plan for further down the road.

[aha_1980]

@Buckwheat The problem here is, that it is no warning but an error which blocks the complete build

I can understand that in this case it's more important to be able to move on first.

I fully agree, however, that this and other warnings should be treated with respect (I already wrote it above).

Regards

[Buckwheat]

@aha_1980 It is never less important to move on if you have a solution that is the correct solution and want to fish for the less safe and proper. How much time was spent trolling for the answer to the question when he already knew the answer.

[Sprezzatura]

@aha_1980, @Buckwheat Thank you very much! This is very helpful.

Don't worry, this code has been in production for twenty-five (25) years, and has run on hundreds of thousands of desktops. It was first written with compilers that didn't have 'const'! We'll deal with it when we have a program that runs. It's all good :o)