After updating to Visual Studio 2015 Update 3 (from Visual Studio 2015), this code no longer compiles:
#include<cmath>
#include<complex>
int main()
{
std::complex<double> update(0.0, 0.0);
double x = std::abs(update);
return 1;
}
I am getting the following error when running the compiler:
c:\projects\foo\win64>cl /EHsc /fp:strict foo.cc
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24213.1 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
foo.cc
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xcomplex(232): er
ror C2131: expression did not evaluate to a constant
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xcomplex(232): no
te: failure was caused by an undefined arithmetic operation
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xcomplex(253): no
te: see reference to function template instantiation '_Ty std::_Fabs<double>(con
st std::complex<double> &,int *)' being compiled
with
[
_Ty=double
]
foo.cc(6): note: see reference to function template instantiation '_Ty std::abs<
double>(const std::complex<double> &)' being compiled
with
[
_Ty=double
]
This issue seems to be tied with my usage of fp:strict, which is necessary for proper IEEE floating point. Is this an issue with my code?
I test it in VS2013 with update 5 and VS2015 with update 3, it really has this issue in VS2015, but everything compiled normally in VS2013 with the same property settings /fp:strict. I help you submit a new feedback to the connect report here:
https://connect.microsoft.com/VisualStudio/feedbackdetail/view/3101450/c2131-expression-did-not-evaluate-to-a-constant-error-in-vs2015-update-3
Maybe the report team could provide better solution for this issue. You could vote it.
Related
In this simple C++20 program
#define _SILENCE_CXX20_U8PATH_DEPRECATION_WARNING //suppress VS warning
#include <filesystem>
int main()
{
auto p = std::filesystem::u8path(u8"a");
}
I get the error from Visual Studio 2019 16.10.0 in stdcpplatest mode:
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\include\filesystem(279,13): error C2338: invalid value_type, see N4810 D.17 [depr.fs.path.factory]/1
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\include\filesystem(346): message : see reference to function template instantiation 'std::wstring std::filesystem::_Convert_stringoid_to_wide<_Conversion>(const std::basic_string_view<char8_t,std::char_traits<char8_t>>,_Conversion)' being compiled
1> with
1> [
1> _Conversion=std::filesystem::_Utf8_conversion
1> ]
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\include\filesystem(1442): message : see reference to function template instantiation 'std::wstring std::filesystem::_Convert_Source_to_wide<char8_t[2],std::filesystem::_Utf8_conversion>(const _Src (&),_Conversion)' being compiled
1> with
1> [
1> _Src=char8_t [2],
1> _Conversion=std::filesystem::_Utf8_conversion
1> ]
1>test.cpp(298): message : see reference to function template instantiation 'std::filesystem::path std::filesystem::u8path<char8_t[2],0>(const _Src (&))' being compiled
1> with
1> [
1> _Src=char8_t [2]
1> ]
Except of deprecation of u8path function in c++20, I do not see anything wrong here, and the code compiles fine in gcc 11 and clang 12 with the options -std=c++20 -Wall, without any warnings. Please help to find what is wrong here.
The ability for u8path to take char8_t was a relatively late addition to the C++20 standard. The error in question cites N4810, which was a draft that contains char8_t (as well as overloads for filesystem::path constructors), but the draft was written before u8path was changed to take char8_t strings.
So VS simply has not implemented the current version of that part of the standard.
When P0482 (char8_t: A type for UTF-8 characters and strings) was adopted for C++20, it unintentionally resulted in std::filesystem::u8path() no longer accepting u8 prefixed string literals (or char8_t-based strings in general). This was an oversight by the author (me) that was corrected (for C++20) via P1423 (char8_t backward compatibility remediation). Microsoft claims to have implemented P1423 in VS 2019 16.6 (19.26), but it seems not so for at least this part of that proposal. Testing on godbolt.org demonstrates that VS 2019 16.2 (19.22) through VS 2019 16.8 (19.28) and the latest preview release all reject calls to std::filesystem::u8path() with a u8 prefixed string literal when compiled with /std:c++latest (gcc, clang, and icc all accept the test in their C++20 conformance modes).
Github user fsb4000 has already reported this issue to the Microsoft STL maintainers (apparently in response to this stackoverflow post).
This constexpr code does not compiled in Visual Studio 2013 version 12.0.21005.1 REL
Is there a newer Visual Studio compiler that works with constexpr?
#include <iostream>
constexpr int factorial(int n)
{
return n <= 1 ? 1 : (n * factorial(n - 1));
}
int main(void)
{
const int fact_three = factorial(3);
std::cout << fact_three << std::endl;
return 0;
}
output from compilation:
1>------ Build started: Project: Project1, Configuration: Debug Win32 ------
1> Source.cpp
1>....\source.cpp(3): error C2144: syntax error : 'int' should be preceded by ';'
1>....\source.cpp(3): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Herb Sutter mentions constexpr on his blog but is unclear in what version it works / will work? http://herbsutter.com/2013/09/09/visual-studio-2013-rc-is-now-available/#comment-13521
Microsoft publishes a C++11 compatibility table, under which constexpr is clearly marked as not being available in Visual Studio 2013.
The November 2013 CTP has it, though.
Source: Google visual studio constexpr
constexpr is not supported in Visual Studio 2013 RTM, see the compatibility table. This is not only true for the RTM version, but also for the Visual Studio Updates.
If you want to stick to Visual Studio 2013, you could download the Visual C++ Compiler November 2013 CTP which comes with some new features, see MSDN blog. Unfortunately Microsoft has no merger with the latest Visual Studio Update features and the CTP features and clearly states that they don't plan to do so.
If we want it all, we need to wait for Visual Studio 2015, see the MSDN blog about VS 2015 Preview.
As is mentioned by the others, November 2013 Customer Technology Preview(CTP) will give you access to constexpr*
Note that just downloading the you'll need to change your "Platform Toolset" to "Visual C++ Compiler Nov 2013 CTP (CTP_Nov2013)" to use the new compiler. You can do that by opening your project's "Property Pages" And going to: "Configuration Properties" > "General" and then changing the "Platform Toolset".
*There is a bit of conflicting information on what portion of constexpr you actually have access to, but it's definitely not all of the standards definition of constexpr. Microsoft says here that the November 2013 CTP adds:
constexpr support (except for constructors)
Microsoft say here that it contains:
constexpr (except for member functions)
I can't even test if it has support for member functions, cause it definitely doesn't have support for any type of constexpr construction. For example this code gives this error with the November 2013 CTP:
error C2127: illegal initialization of 'constexpr' entity with a non-constant expression
One additional note: At time of writing the Visual Studio 2015 Preview still does not support constexpr construction. Keeping my fingers crossed on the final release.
You need to install VS2013 Update 5. (I was on Update 3 and it was not working)
The thing about "Nov 2013 CTP" was inapplicable, as of this writing.
You can do so by going here: https://my.visualstudio.com
and going to download, or :
https://my.visualstudio.com/Downloads?q=visual%20studio%202013
I am attempting to compile/link my file named test.cpp from the command line using VS2017 on a 64-bit Win10 system. I use these two commands:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
cl test.cpp
and I get the following results:
C:\temp\tests>"C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.4.5
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
C:\temp\tests>cl test.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25547 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
test.cpp
test.cpp(2): error C2365: 'y1': redefinition; previous definition was 'function'
C:\Program Files (x86)\Windows
Kits\10\include\10.0.16299.0\ucrt\corecrt_math.h(984): note: see declaration of 'y1'
test.cpp(5): error C2659: '=': function as left operand
My file contains the following code:
#include <new>
static int *y1;
int main()
{
y1 = new (std::nothrow) int;
}
While I understand why this is happening and any number of kluges that will fix it, it seems to me that the actual defect is in the Microsoft corecrt_math.h header file. When I look there I see several more identifiers (j0, jn, jn, etc.) that could just as easily be legitimately chosen by an unsuspecting programmer, only to end up with the same problem. I was under the impression that there was a "gentlemen's agreement" that exposed undocumented identifiers in library code would start or end with an underbar and user code would not, just to avoid this type of problem.
This build command works for me:
cl foo.cpp /Feb /D _CRT_DECLARE_NONSTDC_NAMES=0
I am using Visual studio version 14.0.25431.01 Update 3. While upgrading an existing project in C++ from VS2k13 to VS2k15, I am getting the following build errors in xlocnum file placed at C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum.
Error C2912 explicit specialization 'void std::numpunct<char>::_Getvals(void)' is not a specialization of a function template Scripttest C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum 192
and
Error C2061 syntax error: identifier '_Elem2' InterPTest C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum 188.
Following code in xlocnum is throwing the error
template<_Elem2>
void _Getvals(_Elem2, const lconv *_Ptr, _Locinfo::_Cvtvec _Cvt)
{ // get values
_Dp = _MAKLOCCHR(_Elem2, _Ptr->decimal_point[0], _Cvt);
_Kseparator = _MAKLOCCHR(_Elem2, _Ptr->thousands_sep[0], _Cvt);
}
After explicitly typenameing template<_Elem2> with template, error resolves but the change has to be made in the windows file xlocnum itself, so its doesn't seem a valid solution. Please suggest a resolution for this issue, Thanks
I have a strange situation here. I am trying to use the Botan crypto library with VS2015 (because some other parts of the project use some heavy C++11 code which VS2013 is unable to compile) and I get a pretty long compilation error (see below).
After trying out various things, I came to the conclusion, that even if one of the botan headers is included in the compiled c++ source file, the compiler will throw the error below. Right now I have a single line in the file:
#include <botan/botan.h>
and this is the error I get:
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(876): error C2664: 'Botan::secure_allocator<_Newfirst>::secure_allocator(const Botan::secure_allocator<_Newfirst> &)': cannot convert
argument 1 from 'std::_Wrap_alloc<Botan::secure_allocator<Botan::byte>>' to 'const Botan::secure_allocator<_Newfirst> &'
with
[
_Newfirst=std::_Container_proxy
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(876): note: Reason: cannot convert from 'std::_Wrap_alloc<Botan::secure_allocator<Botan::byte>>' to 'const Botan::secure_allocator<_Ne
wfirst>'
with
[
_Newfirst=std::_Container_proxy
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(876): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(587): note: see reference to function template instantiation 'std::_Wrap_alloc<Botan::secure_allocator<_Newfirst>>::_Wrap_alloc<std::_Wr
ap_alloc<Botan::secure_allocator<Botan::byte>>>(_Other &) noexcept' being compiled
with
[
_Newfirst=std::_Container_proxy,
_Other=std::_Wrap_alloc<Botan::secure_allocator<Botan::byte>>
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(587): note: see reference to function template instantiation 'std::_Wrap_alloc<Botan::secure_allocator<_Newfirst>>::_Wrap_alloc<std::_Wr
ap_alloc<Botan::secure_allocator<Botan::byte>>>(_Other &) noexcept' being compiled
with
[
_Newfirst=std::_Container_proxy,
_Other=std::_Wrap_alloc<Botan::secure_allocator<Botan::byte>>
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(585): note: while compiling class template member function 'void std::_Vector_alloc<std::_Vec_base_types<_Ty,_Alloc>>::_Free_proxy(void)
'
with
[
_Ty=Botan::byte,
_Alloc=Botan::secure_allocator<Botan::byte>
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(552): note: see reference to function template instantiation 'void std::_Vector_alloc<std::_Vec_base_types<_Ty,_Alloc>>::_Free_proxy(voi
d)' being compiled
with
[
_Ty=Botan::byte,
_Alloc=Botan::secure_allocator<Botan::byte>
]
C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\vector(679): note: see reference to class template instantiation 'std::_Vector_alloc<std::_Vec_base_types<_Ty,_Alloc>>' being compiled
with
[
_Ty=Botan::byte,
_Alloc=Botan::secure_allocator<Botan::byte>
]
c:\Botan\include\botan-1.11\botan/rng.h(43): note: see reference to class template instantiation 'std::vector<Botan::byte,Botan::secure_allocator<Botan::byte>>' being compiled
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3.0\VC\bin\cl.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Since I was able to compile and run the botan tests, I have the feeling that I missed something, but I have no idea what. Does anyone has any experience with this?
(BTW: The same code compiles nicely with g++ 4.9)
Looking at the sources, it seems that Botan::secure_allocator doesn't provide a template constructor of the form
template<class U> secure_allocator(const secure_allocator<U>& other);
This is required by the Standard. In the current working draft, N4527, the relevant bits are in [17.6.3.5] Table 28 - Allocator requirements; also useful is the example in paragraph 9.
So, we can't blame the standard library implementation that comes with VC 14 for requiring this in order to compile. The error is on Botan's side in my opinion.
A quick fix is to add such a definition to Botan::secure_allocator:
template<class U> secure_allocator(const secure_allocator<U>&) BOTAN_NOEXCEPT { }
Since instantiations of this allocator template don't have any non-static data members, an empty body should be fine. However, I'm not familiar with the library, and we're talking about cryptography here, so, before using this to do any serious stuff, please confirm the change with the library authors.
Another possible workaround:
I've noticed that the code that calls the mixed-type constructor seems to only be enabled when iterator debugging is enabled, which happens by default in Debug mode.
Have you tried compiling in release mode? If my observations are correct, you won't get this error anymore, since the additional machinery for iterator debugging will be disabled.
To get the same behaviour in Debug mode, set the _ITERATOR_DEBUG_LEVEL macro to 0 globally.
Debug iterators can be useful to detect errors (as long as the performance hit doesn't affect you), so I wouldn't use this as a permanent fix, but it could be useful as a temporary workaround if you don't want to modify the Botan header file.
This could also explain why you were able to compile the tests: maybe they're compiled in release mode, or, anyway, with a combination of settings that disables iterator debugging?