Ambiguous call to overloaded function

[bcollins526]

I'm using json object with Electronic Arts' EASTL library, just like in #2059, and after a recent json update, I get:

1>P:\bcview\external\json\include\nlohmann\detail\input\input_adapters.hpp(377,1): error C2668: 'eastl::begin': ambiguous call to overloaded function (compiling source file ..\src\materialcache.cpp)
1>P:\bcview\external\EASTL\include\EASTL\iterator.h(1074,34): message : could be 'const char *eastl::begin<ContainerType>(const Container &)' [found using argument-dependent lookup]
1>        with
1>        [
1>            ContainerType=bc9::stdstring,
1>            Container=bc9::stdstring
1>        ] (compiling source file ..\src\materialcache.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\xutility(1966,30): message : or       'const char *std::begin<ContainerType>(const _Container &)'
1>        with
1>        [
1>            ContainerType=bc9::stdstring,
1>            _Container=bc9::stdstring
1>        ] (compiling source file ..\src\materialcache.cpp)
1>P:\bcview\external\json\include\nlohmann\detail\input\input_adapters.hpp(377,1): message : while trying to match the argument list '(const ContainerType)'

It seems to be having a problem here (in input_adapters.hpp):

template<typename ContainerType>
auto input_adapter(const ContainerType& container) -> decltype(input_adapter(begin(container), end(container)))
{
    // Enable ADL
    using std::begin;
    using std::end;

    return input_adapter(begin(container), end(container));
}

I worked around the issue locally by just adding std::

    return input_adapter(std::begin(container), std::end(container));

but doesn't seem like I should've had to do that?

I've got json commit 7444c7, Windows 10, MSVC 2019.

[nlohmann]

Is EASTL somehow available to reproduce this locally?

[bcollins526]

Yes, it's available here:
https://github.com/electronicarts/EASTL

[nlohmann]

Thanks! Can you also provide a small self-contained example?

[bcollins526]

So assuming you've got EASTL headers available, this guy should fail to compile (disregarding here that s isn't actually initialized to anything):

#include "EASTL/string.h"
#include "nlohmann/json.hpp"

template <typename T>
using mybasicstring = eastl::basic_string<T>;
typedef mybasicstring<char> mystring;

using myjson = nlohmann::basic_json<std::map,
                                    std::vector,
                                    mystring,
                                    bool,
                                    int64_t,
                                    uint64_t,
                                    double>;
void TestFunc() {
    mystring s;
    myjson testjson = myjson::parse(s);
}

but adding std:: as described above to input_adapters.hpp lets it compile ok.

You shouldn't have to compile EASTL to see the error.

I originally wanted to have the json using directive use only EASTL containers, but I had problems with getting json to work with EASTL's map and vector, so I've been using it with std versions of those containers for the past few months and it's been working.

[jaredgrubb]

Looks like Catch2 also hit this:
catchorg/Catch2#1882

Sounds like it might be EASTL bug, which they aren't inclined to fix (cf electronicarts/EASTL#73 "std interop isn't a heavily used feature" or electronicarts/EASTL#356).

[bcollins526]

I wouldn't say it's an EASTL bug really. Since EASTL is intended to provide a complete replacement of std's containers, iterators, and algorithms, it's not really surprising (or even expected really) that they would provide std interop.

It would be a drag if, in the end, there's all this template machinery in place to allow for implementations other than std, but in practice it doesn't work because ADL isn't able to select a "preferred" option from the two choices. If there was some way I could work around this locally, with a little extra code or whatever, I'd be cool with that. This does seem like a weird situation though, need to think on this...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.