json-validator.cpp(594): error C2593: 'operator =' is ambiguous

[aholzinger]

Compiling for x64 with dynamic runtime and Visual Studio 2019 with vcpkg I get the above error.

This patch fixes the error:
aholzinger@e76dc74

[garethsb]

Strangely, VS 2019 compiles that file with no problems for me, though Intellisense does show it as ambiguous.

[aholzinger]

Yes, for me it's also depending on the type of runtime used. It doesn't compile under 64 bit with dynamic runtime.

[garethsb]

That's my default config and it's working. Very strange...

[aholzinger]

Perhaps depending on include order?

It happended for me when building with vcpkg.

There's also this ugly 'U' macro definition in cpprestsdk which is breaking some boost traits header due to a template parameter namded 'U' there. I guess you will have figured out this already.

[garethsb]

https://github.com/sony/nmos-cpp/blob/master/Development/cpprest/details/boost_u_workaround.h

[garethsb]

Perhaps depending on include order?

If you haven't changed the code, we should be testing the same include order...

It happended for me when building with vcpkg.

Would that mean you have a different version of JSON For Modern C++?

Can you confirm your VS 2019 build, and which toolset, you are using?

[aholzinger]

I haven't changed the code, I just found out that I didn't yet install nmos-cpp from my github repo on all vcpkg triples I use (x86-windows-static, x86-windows, x64-windows-static, x64-windows). So I tried to install it with x64-windows and it gave me the ambiguity error. I then made the fix and afterwards all four triples compiled/installed fine.

I can't say how building with vcpkg changes something with the include order. Surely only headers from within vcpkg will be used (plus the ones of VStudio).

The 'U' issue I encountered in my project where I want to use nmos-cpp when I included some nmos-cpp header. Undoubtedly you knew that one and already made a workaround. THanks for the link. I didn't yet stumble upon it.

[aholzinger]

No, no different JSON, just building/installing via vcpkg with the outer CMakeLists.txt and the code in my github repo.

Do you want me to build your repo with CMake?

Would making use of vcpkg (for cpprestsdk, openssl, etc.) be okay?

[garethsb]

I'm sorry, we've investigated and can't reproduce this, so I suspect something different in your environment or a very weird compiler bug. If you can make a minimal repro of the issue, let us know.

[aholzinger]

Have you tested with VS 2019 16.5?

I think the reason is this (nlohmann/json.hpp line 15623):

template < typename ValueType, typename std::enable_if <
                not std::is_pointer<ValueType>::value and
                not std::is_same<ValueType, detail::json_ref<basic_json>>::value and
                not std::is_same<ValueType, typename string_t::value_type>::value and
                not detail::is_basic_json<ValueType>::value

#ifndef _MSC_VER  // fix for issue #167 operator<< ambiguity under VS2015
                and not std::is_same<ValueType, std::initializer_list<typename string_t::value_type>>::value
#if defined(JSON_HAS_CPP_17) && (defined(__GNUC__) || (defined(_MSC_VER) and _MSC_VER <= 1914))
                and not std::is_same<ValueType, typename std::string_view>::value
#endif
#endif
                and detail::is_detected<detail::get_template_function, const basic_json_t&, ValueType>::value
                , int >::type = 0 >
operator ValueType() const
{
    // delegate the call to get<>() const
    return get<ValueType>();
}

So I think we must either use my proposed workaround or make Niels Lohmann change his code. When you look at the first #ifdef to me it looks like a hack (what sense does it make to test for _MSC_VER afterwards?).

My guess is that VS 2019 16.5 brings this problem back, because this VS version would need the line

                and not std::is_same<ValueType, std::initializer_list<typename string_t::value_type>>::value

because it's the std::initializer_list operator that creates the ambiguity.

Thanks to s13n for pointing me to the right _direction.

[garethsb]

Have you tested with VS 2019 16.5?

You like living on the edge then, the release announcement is just one week old. :-)

I'm testing with VS 2019 16.4.6. I'll install 16.5 to see if I can repro.

I completely agree those preprocessor conditions look bogus. I know the implicit conversions are an area which has caused lots and lots of issues for nlohmann/json.

[aholzinger]

My very much appreciated ex research boss always said "Implicit conversions are evil!". I think he's right :-)

(I frequently (well in the past, before corona virus) have an internet connection based on a limited (in terms of GB per month) mobile connection, so it became routine to make a VS update when I have VDSL :-)

I don't currently have to release any VS2019 (releases all use VS2017 to date) so I can play around :-)

[garethsb]

Reproduced with VS 2019 16.5.0 as discussed in recent comments on nlohmann/json#188.

[garethsb]

Still waiting for nlohmann/json#2008 to be merged...

[garethsb]

Need to try out https://github.com/nlohmann/json/releases/tag/v3.8.0

[garethsb]

@jonathan-r-thorpe, @aholzinger, I think this can be closed, resolved some time ago by cba288e

[lo-simon]

resolved by cba288e