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).
Related
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.
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?
While playing around with the C++11 features of Visual Studio 2012, I encountered strange errors when including the "ppltasks.h" header file (which is included via the "future" header file:
Main.cpp
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\ppltasks.h(3306): error C2512: 'Concurrency::details::_PPLTaskHandle<Concurrency::details::_NormalizeVoidToUnitType<void>::_Type,Concurrency::task<std::pair<Concurrency::details::_Unit_type,Concurrency::details::_CancellationTokenState *>>::_ContinuationTaskHandle<_InternalReturnType,_TaskType,_Function,Concurrency::details::_FunctionTypeTraits<_Function,_ReturnType>::_Takes_task,Concurrency::details::_TaskTypeTraits<void,false>::_AsyncKind>,Concurrency::details::_ContinuationTaskHandleBase>' : no appropriate default constructor available
1> with
1> [
1> _InternalReturnType=std::pair<Concurrency::details::_Unit_type,Concurrency::details::_CancellationTokenState *>
1> , _Function=Concurrency::||::<lambda_06496b162c644bf2f90c850c3dfa7d5c>
1> , _ReturnType=std::pair<Concurrency::details::_Unit_type,Concurrency::details::_CancellationTokenState *>
1> ]
The error is longer, but you get the gist of it. Has anybody else encountered such an error message from simply including the "future" header, and is there a known solution? Thanks.
Turns out that the Project Settings must have language extensions enabled for the header to compile correctly (as of now).
Disclaimer: it's just another task for beginner so I'm good with the fact that on different compilers and on different architectures I may get different (incompatible) binaries as a result. So it's ok that it will only work only on this particular machine.
I'm writing and reading size_t from a binary file. Writing looks like:
std::string result;
result.append((char *)&block_size_, sizeof(block_size_));
and soon after that result is written to a file.
But when I read it in a same way:
map_binary.copy((char *)&block_size_, sizeof(block_size_), offset);
I get a warning
warning C4996: 'std::basic_string<_Elem,_Traits,_Alloc>::copy': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
1> with
1> [
1> _Elem=char,
1> _Traits=std::char_traits<char>,
1> _Alloc=std::allocator<char>
1> ]
1> c:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring(1777) : see declaration of 'std::basic_string<_Elem,_Traits,_Alloc>::copy'
1> with
1> [
1> _Elem=char,
1> _Traits=std::char_traits<char>,
1> _Alloc=std::allocator<char>
1> ]
I cannot get why this code is unsafe and looking for a solution other than pretending there is no issues at all (using the -D_SCL_SECURE_NO_WARNINGS).
So, what am I missing?
PS: right now I'm learning C++ using only standard library, so solutions that use boost or something else are unacceptable.
You're not missing anything. VC++ is very keen to warn you if you copy anything to a pointer. In this case there is no guarantee that you will get the size of destination correct. After all you might write something like this map_binary.copy((char *)&block_size_, 4, offset); and then find your code fails with a 64-bit compiler.
If you're happy with your ability to avoid this kind of error then disable or ignore the warning.
I am working on porting our C++ code from eVC 4.0 to Visual Studio 2008. Our target is Windows Mobile 6.1 and we are using the Windows Mobile 6.0 SDK for our app.
Our code used stl port when compiled in eVC 4 and we would like to continue to use stl port if at all possible.
Does anyone know what steps are necessary to incorporate STL port (5.2.1) in our application. We have set the include directories in the solution (as we did for the eVC 4.0 project), but we are seeing the errors (below) any time we try to use list push_back or vector insert commands with our own classes (below is the error with our class "TriangleBufferElement"). These commands do seem to work with native types like int, double, etc.
We have ensured all classes have the proper contructors, copy constructors, assignment operators, and comparison operators and all appear to be correct.
Any ideas?
C:\Program Files\Windows CE Tools\stlport\stl/_construct.h(119) : error C2665: 'operator new' : none of the 2 overloads could convert all the argument types
1> C:\Program Files\Windows Mobile 6 SDK\PocketPC\include\../../../Windows Mobile 6 SDK\PocketPC\Include\Armv4i/new(61): could be 'void *operator new(unsigned int,const std::nothrow_t &) throw()'
1> while trying to match the argument list '(unsigned int, TriangleBufferElement *)'
1> C:\Program Files\Windows CE Tools\stlport\stl/_construct.h(134) : see reference to function template instantiation 'void stlp_std::_Copy_Construct_aux<_Tp>(_Tp *,const _Tp &,const stlp_std::__false_type &)' being compiled
1> with
1> [
1> _Tp=TriangleBufferElement
1> ]
1> C:\Program Files\Windows CE Tools\stlport\stl/_vector.h(381) : see reference to function template instantiation 'void stlp_std::_Copy_Construct<_Tp>(_Tp *,const _Tp &)' being compiled
1> with
1> [
1> _Tp=TriangleBufferElement
1> ]
1> C:\Program Files\Windows CE Tools\stlport\stl/_vector.h(376) : while compiling class template member function 'void stlp_std::vector<_Tp>::push_back(const _Tp &)'
1> with
1> [
1> _Tp=TriangleBufferElement
1> ]
1> c:\srcdevbranch\pointlib\dtmconverter\dtm\dtmreader\.\trianglebuffer.h(47) : see reference to class template instantiation 'stlp_std::vector<_Tp>' being compiled
1> with
1> [
1> _Tp=TriangleBufferElement
1> ]
Some links you probably should see (if not seen already):
STLPort Notes:
You may experience problems with default SGI node allocator. I had no such problems, though. Default node allocator is quite fast, so I wouldn't recommend disabling it without serious reason. However, if it causes problems, define _STLP_USE_MALLOC or _STLP_USE_NEWALLOC to get bare malloc()-based or new()-based default allocator.
Though this post says it has not yet been ported to VS2008.
Have you reconfigured STLPort for the new compiler environment? Visual Studio 2008 is quite different from the old eVC++ compiler.
Try:
configure evc9
In my case, this was due to __PLACEMENT_NEW_INLINE defined