The following program should compile.
#include "nlohmann/json.hpp"
void foo()
{
std::string s;
nlohmann::json j;
s = j;
}
With Visual Studio 2019 version 16.5.0, the above fails to compile. This is a recent release, but comes under "Microsoft Visual C++ 2019 / Build Tools 16.3.1+1def00d3d (and possibly later)".
The error message is:
foo.cpp(7,10): error C2593: 'operator =' is ambiguous
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.25.28610\include\xstring(2591,19): message : could be 'std::basic_string<char,std::char_traits<char>,std::allocator<char>> &std::basic_string<char,std::char_traits<char>,std::allocator<char>>::operator =(std::initializer_list<_Elem>)'
1> with
1> [
1> _Elem=char
1> ]
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.25.28610\include\xstring(2492,19): message : or 'std::basic_string<char,std::char_traits<char>,std::allocator<char>> &std::basic_string<char,std::char_traits<char>,std::allocator<char>>::operator =(std::basic_string<char,std::char_traits<char>,std::allocator<char>> &&) noexcept(<expr>)'
1>foo.cpp(7,10): message : while trying to match the argument list '(std::string, nlohmann::json)'
develop branch?I tried both a recent release and HEAD of develop.
The same error message is reported when trying to compile test\src\unit-conversions.cpp.
In both cases the error can be resolved by removing the #ifndef _MSC_VER which ends up at https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp#L17468 (and the corresponding #endif!). FWIW, in my testing with VS 2015 (for which that preprocessor condition was added), the code also compiles fine when it is removed.
The compile-time and preprocessor conditions to enable implicit conversions have obviously been revisited many times over the life of nlohmann/json. A good place to start looking at the history is https://github.com/nlohmann/json/pull/188.
Unfortunately appveyor [1] is still at 16.4.
But nevertheless can you provide a PR based on your findings? It might be easiest to first try dropping the #ifndef altogether.
Thanks @garethsb-sony !
With #2008 merged, can this issue be closed?
From my side, yes, my issue is fixed.
Most helpful comment
Unfortunately appveyor [1] is still at 16.4.
But nevertheless can you provide a PR based on your findings? It might be easiest to first try dropping the
#ifndefaltogether.