CODEWITHSUNDEEP
c++visual-studiowarningscompiler-warnings
Jonathan Wood
Jonathan Wood

Reputation: 67193

Do new c++ warnings improve reliability?

So, I've been working in C++ after working in C# for a long time and I notice that there are all these warnings now.

While some warnings appears to be good recommendations to make the code more reliable, it seems like many of them don't. And a number of them seem completely wrong.

Here's an example of one that doesn't seem worthwhile to me:

static TCHAR szGeneral[] = _T("General");
static TCHAR szSqlOdbcDriver[] = _T("SqlOdbcDriver");

WriteProfileString(szGeneral, szSqlOdbcDriver, CSqlServerDatabase::m_sOdbcDriver.GetString());

Warning C26485 Expression 'szGeneral': No array to pointer decay (bounds.3).

Warning C26485 Expression 'szSqlOdbcDriver': No array to pointer decay (bounds.3).

My question is: does this make my code better?

I submit that I've had to turn off warnings because my project has almost 800 of them. (The code was considered perfectly valid when it was written ten years ago.) And so I will miss all the good recommendations. And the result of that would be that my code is worse.

Upvotes: 0

Views: 330

Answers (2)

Eugene
Eugene

Reputation: 7468

Note that this warning comes from Core Guidelines checker recently added to Visual Studio. Warnings from this checker will only make sense when you are writing new code from scratch and ready to follow Core Guidelines. Otherwise, turn off the checker.

The checker is a part of static code analyzer, and you should probably not include the analyzer in your compilation.

In your project properties, you have /analyze in C/C++-->Command Line. You should get rid of this flag (I do not know how to do it for your version of Visual Studio).

Do not turn off all warnings.

Upvotes: 2

fadedreamz
fadedreamz

Reputation: 1156

IMO it is situation dependent. For example, the compiler is giving warning because as soon as you are passing the char[] to the function you are losing the sizeof() information. However, that might not even matter as the strings are null terminated. But consider the case where somehow the nullptr is gone. Then how would you compute the length of it in the function?

To assist the compiler in such cases, I would recommend to explicitly tell compiler that you know what you are doing. This also makes intent visible. consider -

long b = 50;
int a = b;

will generate a compiler warning, but depending upon the usage it might be safe. but you are leaving team members with a guess (is it intended or error?). Where

long b = 50;
int a = static_cast<int>(b);

makes clear that it is intended.

Upvotes: 2

Related Questions