I am trying to test a little C++17. I am trying to do:
[[nodiscard]] int get_value1()
{
return 42;
}
inline void start()
{
// Should generate warning
get_value1();
}
However, it does not. I am using Visual studio 2017. Warning level set to Level4(\W4). I have set C++ Language Standard to ISO C++ Latest Draft Standard (/std:c++latest).
But it does not generate the warning that I want. Why is that? Also, a little side question: That tab to select the language standard only appears in Debug configuration and not Release. Why is that? Release complains on the nodiscard, Would that mean that Release is in C++14?
edit: naturally I meant warning in the second section. Corrected. :)
Actually [[nodiscard]] is supported only since VS 2017.3 and it should give you a warning, not an error. And as I understand specification assumes that compiler may warn you. And may not.
Related
C++11 allows initializing a value with zero using the expression T(); (http://en.cppreference.com/w/cpp/language/zero_initialization). Is this feature supported by Visual Studio 2010? I ran some experiments comparing T x; with T x = T(); and I concluded that the latter case does initialize the value with zero, but I am not sure whether I can rely on that.
Is zero initialization mentioned anywhere in the VS2010 documentation? The VS2010 Initializers page (https://msdn.microsoft.com/en-us/library/w7wd1177(v=vs.100).aspx) does not mention it, unlike pages for later versions, e.g., VS2013 (https://msdn.microsoft.com/en-us/library/w7wd1177(v=vs.120).aspx).
This is a fundamental behaviour of the language that has been in there since the start. It was not introduced in C++11 (on that cppreference page note that "since C++11" is aligned with only the third of the examples under usage (2); granted it's not very clear).
If T were int and T() did not result in a temporary int of value zero (and this is zero-initialisation via value-initialisation), the compiler would have a very serious bug. I am sure that Visual Studio does not have this bug.
As for proof, the VS2010 docs do not seem to mention this behaviour in the same place the standard mentions it (i.e. under the explicit type conversion expression section). It is certainly possible that their documentation has changed/evolved/become more thorough over time, though, particularly as C++ itself added more and more ways to initialise things.
I try to build CRF++ in Visual Studio 2013 and get this error in the last line:
array_[begin + siblings[i].code].base =
value_ ?
static_cast<array_type_>(-value_[siblings[i].left]-1) :
static_cast<array_type_>(-siblings[i].left-1);
error C4146: unary minus operator applied to unsigned type, result
still unsigned
Specifically, it is in darts.h, line 189.
I built again in Visual Studio 2015 then there is no error.
How can I fix this in Visual Studio 2013?
C4146 is not supposed to be an error. It is a mere warning. If you see it as an error in your case, it means that someone has configured it this way, most likely unintentionally. This makes no sense.
Find and undo the changes that turned it into an error. Then you can disable it if you wish.
For others I wanted to add another answer in case they stumble into that bug like me.
Even if "Threat warning as error" was off in my compiler, I had to compile my project with #pragma warning(disable:4146) in my header's file that was showing me the error. For you it would had been inside darts.h
Please note disabling the warning globally in my project was not working (compiler /wd4146), the pragma line was needed in the header's file directly.
the siblings variable also has unary minus applied to it, maybe that is the culprit? Also if it's templated code you cannot really be sure value_ is going to be be short, int or long unless that is asserted via static_assert or so. We can only guess as you don't provide information about what types are actually used or something reproducable. Also did you use the exact same project for compilation in VS2015? If not, the warning might just have been disabled there.
Anyway, suppose it is a bug in VS2013, it likely won't ever get fixed anymore so you can try to find a workaround. Start by breaking that statement down into smaller ones until you know exactly which part is the problem (or maybe, by then the problem is gone already as it goes with compiler bugs). Then suppress the warning with #pragma warning ( disable : 4146 ), wrapped in a conditional directive so it only has effect for VS2013 #if _MSC_VER > 1800 && _MSC_VER < 1900 should do fine. Enable the warning again after the statement. Add a comment as to why the warning is disabled and submit the changes as a patch to CRF++.
Try this:
int tmp = static_cast<int>(siblings[i].left);
array_[begin + siblings[i].code].base =
value_ ?
static_cast<array_type_>(-value_[siblings[i].left]-1) :
static_cast<array_type_>(-tmp - 1);
For anyone running into the really confusing part of this:
This isn't supposed to be an error. In fact, there are a bunch of warnings that Visual Studio incorrectly turns into errors by default. Compilers can add warnings for whatever they want, but throwing errors for valid code is just a bug.
The culprit is the "SDL checks" option. It's known for adding things like runtime stack checking, which is fine, but they snuck a bit of nastiness in: "and enables extra security-relevant warnings as errors". That needs to be turned off to have something slightly closer to a standard C++ compiler.
When use Eclipse with MinGW(version:4.8.1) to compile the following code fragement, it can pass but Eclipse still report:
"Multiple markers at this line - Type 'alignas' could not be resolved"
template<typename X> void set_aside(std::vector<X> vx) {
constexpr int max_buf = 1024;
alignas(X) X buffer[max_buf];
int max = min(vx.size(), max_buf / sizeof(X));
std::uninitialized_copy(vx.begin(), vx.begin() + max, buffer);
}
What happend with this issue, although the code fragement pass the comiple,yet Eclipse marks with error.
Someone have ever met this issue? Please kindly help me to resolve this issue,thanks very indeed!
Many IDEs use a front-end syntax checker that is different than their back-end compiler. Eclipse Kepler (released June 2013) is mostly up-to-date with C++11 syntax, although some things like alignment support and the interaction with in-class initializers and default constructors might not be fully supported (yet). Similary, C++14 features like decltype(auto) will work if the back-end compiler is called with std=C++1y but will not be recognized by the front-end syntax checker.
NOTE: this is not unique to Eclipse, also Visual C++ Intellisense is sometimes running behind (especially in CTP versions) the actual compiler, causing the red squiggly lines.
While qualifying an enumeration value with the name of the enumeration is not valid C++03, it is valid C++11, from what I understand. Despite this, MSVC 10 generates warning C4482 for the following:
enum E { A, B };
int i = E::A; // warning C4482 (but valid C++11?)
Since much of our code uses C++11 features (especially lambdas), it seems safe to disable this warning. Am I right that the code is valid C++11?
Note: I did not write the code in question, and I would prefer to not go through and change every occurrence of this.
Edit: Added some relevant links.
MSDN page for the warning.
Another question about the warning. The question and answers all seem to reference C++03.
Since much of our code uses C++11 features (especially lambdas), it seems safe to disable this warning.
If you're already relying on C++11 features, then yes. C++11 does allow you to use regular enums scoped by the enumeration's name. Microsoft had this as an extension for some time, so they issued a warning about the non-standard behavior.
So you can disable it.
Note that older compilers like VC2010, instead of warning, did raise compile error C2653 (with message "... is not a class or namespace name").
I want to play with constexpr, does any compiler support it yet?
The Apache Stdcxx project has a nice table detailing which C++0x features are supported by which compilers. It's been updated on a regular basis and covers most of the modern C++ compilers.
According to that, only GCC 4.5 supports constexpr (note that that support may be experimental).
Between that list and what has been said in the comments, it appears the answer is "no."
As of July 2011, gcc 4.7 supports constexpr. You need to build it from svn though.
Agreed, g++ 4.5 and 4.6 support the keyword, but ignore the implications. I just compiled a simple factorial program (on both versions using -std=c++0x) with the line:
constexpr fact(int i) { return (i>1) ? fact(i-1)*i : 1; }
and it compiled and ran but when examining the asm source (-S option) it showed the function was called with the parameter instead of being determined by the compiler.
Usage of "constexpr" is really easy. Look at this piece of code:
constexpr int get_five(){
return 5;}
This function returns always 5, so it can be declared with "constexpr" keyword.
But factorial function returns value depending on argument, so its "output" is not always the same.