I was reviewing some of my cSuneido C++ code and I noticed that I was ignoring the return value from a function, which meant that a variable might not be set. The function looked like:
bool int_if_num(int* pi);
I recalled reading about the new (C++17) [[nodiscard]] attribute which should catch this kind of error. I added the attribute to the function:
[[nodiscard]] bool int_if_num(int* pi);
I thought it was supported in Visual Studio but it turned out that it's "coming soon" in the next release.
But I also had Clang which does support it, and sure enough it caught the error:
error: ignoring return value of function declared with 'nodiscard' attribute
(I thought there might be more instances, but this was the only one.)
The nice thing about this kind of feature is that it's fine if it doesn't have universal support. I commonly compile with GCC and Clang in addition to Visual Studio because they each catch different issues.
[Afterward - reading the code more carefully, I found that I was initializing the variable prior to the call so it wasn't a problem after all. But that relied on the function not modifying the value unless it succeeded, which could change, and then there would be a problem. So it was still worth fixing the code.]
bool int_if_num(int* pi);
I recalled reading about the new (C++17) [[nodiscard]] attribute which should catch this kind of error. I added the attribute to the function:
[[nodiscard]] bool int_if_num(int* pi);
I thought it was supported in Visual Studio but it turned out that it's "coming soon" in the next release.
But I also had Clang which does support it, and sure enough it caught the error:
error: ignoring return value of function declared with 'nodiscard' attribute
(I thought there might be more instances, but this was the only one.)
The nice thing about this kind of feature is that it's fine if it doesn't have universal support. I commonly compile with GCC and Clang in addition to Visual Studio because they each catch different issues.
[Afterward - reading the code more carefully, I found that I was initializing the variable prior to the call so it wasn't a problem after all. But that relied on the function not modifying the value unless it succeeded, which could change, and then there would be a problem. So it was still worth fixing the code.]
