Just a heads up to let you know that Pluralsight is currently offering a 40% off deal for a limited time.
Click the banner below to save now!
Giovanni Dicanio's C++ Corner on the Internet
C++ programming language and libraries (not platform-specific)
Just a heads up to let you know that Pluralsight is opening up its platform with thousands of video courses for the entire weekend (November 18th-20th).
This means that you can watch all the courses you want for free during this weekend!
Are you interested in getting started with the C language? Or do you want to learn about Data Structures and Algorithms in C++?
All my courses, as well as all the existing courses, are available for free during this weekend.
Don’t miss this opportunity!
Happy learning!
I was working on some Windows C++ code with Visual C++ 2019, and I got the following warning:
Warning C6387:
‘utf16’ could be ‘0’: this does not adhere to the specification for the function ‘std::basic_string_view<wchar_t,std::char_traits<wchar_t> >::{ctor}’.
In general, I compile my C++ code at warning level 4 (/W4), as I like to have the C++ compiler speak up when it detects something that looks wrong to it.
However, in this case I was right and the C++ compiler (code analyzer) was wrong.
In fact, in this particular case, the code analyzer was saying that I had a const wchar_t* utf16 pointer, that could be potentially null (“utf16 could be 0”), and I was passing it to a wstring_view constructor overload that does not expect null pointers.
What the code analyzer did not figure out is that I already checked for the special case of the null pointer value in the if statement just above!
if (detail::IsNullOrEmpty(utf16)) { return std::string{}; }
So, if the utf16 pointer passed the if check, the wstring_view constructor would have certainly received a non-null pointer value.
So, once you are sure that your code is correct and the C++ compiler is wrong, how do you suppress such spurious warnings?
Well, you could think of using a #pragma warning (disable) directive, like this:
// Disable the warning C6387 #pragma warning( disable: 6387 )
The problem with this approach is that you end up disabling that warning for all the following code that gets processed by the C++ compiler, potentially muting warning messages that are legit, and could help you spot subtle bugs!
So, what you really want to do is to locally disable the warning, for the specific line (or lines) of code that you are sure is correct, and then immediately re-enable it for the next code.
To do that, you can use this kind of #pragma push-disable-pop dance:
// Save the current warning state #pragma warning( push ) // Disable the warning locally for just the following code #pragma warning( disable : 6387 ) // Code that is processed with the above warning disabled // Re-enable the previous warning state #pragma warning( pop )
In addition, for a case like the one discussed here, where you just want to temporarily disable a warning for a single line of code, you can use the shortcut #pragma warning (suppress) directive, like this:
#pragma warning( suppress: 6387 ) // Just one line of code for which the warning is suppressed
For the sake of clarity and code maintainability, I usually like to add a comment block, specifying additional information about the compiler version I’m using and the warning number and message, and why I think that that warning is spurious. So, when the same code is compiled with an updated compiler version that is smarter and doesn’t detect the spurious warning anymore, I can completely remove the #pragma warning(suppress) directive.
In the initial version of my WinReg C++ library, I made a design decision that methods that wrapped Win32 Registry C API calls would throw C++ exceptions on errors.
Important feedback I got from the users of this library was that they wanted methods that returned error codes instead of throwing exceptions (e.g., see this issue).
For example, when opening a registry key, folks want to be able to check the result of the operation without having exceptions thrown from failed opens. Similarly when trying to read values from the registry.
This is a good remainder for those C++ devs who think that we should always throw exceptions instead of using error return codes!