Library provides template arg for string_type but assumes std::string in some places

[bcollins526]

I'm using json object with Electronic Arts' EASTL library, which provides high performance implementations of std containers. I use the following typedef:

    using stdjson = nlohmann::basic_json<std::map,
                                         std::vector,
                                         stdstring,
                                         bool,
                                         int64_t,
                                         uint64_t,
                                         double,
                                         jsonallocator,
                                         nlohmann::adl_serializer>;

where stdstring is eastl::string, which is their version of std::string. Then throughout my code, I just always use stdjson type. This works great, except for when json code assumes std::string. For example, this code:

   for (auto& cam : sjson["cameras"].items()) {
        stdstring cameraname(cam.key());
    }

fails to compile because of this code in iteration_proxy.hpp:

template<typename string_type>
void int_to_string( string_type& target, std::size_t value )
{
    target = std::to_string(value);
}

which assumes std::string is the string_type. I'm using Visual Studio 2019 on Windows 10 using the latest release of json.

[ArtemSarmini]

It assumes that string_type is move-assignable or implicitly-move-constructible from std::string which is not true for eastl::string. To fix it we may add some sfinae to construct string_type either from std::to_string(value) or from std::to_string(value).data() which I hope will return something meaningful for all string_types we care of.
Another option is to introduce like convertion_traits in json template args which will handle such stuff. If one uses nonstandard string, one provides nonstandard traits, simple and neat. (It is also a possibility to consider opting in to use std::from_chars. ) Downside is that it is a very major change in api and requires quite lots of work: new code, new tests, new docs.
@nlohmann thoughts?

[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.

[t-b]

To fix it we may add some sfinae to construct string_type either from std::to_string(value) or from std::to_string(value).data() which I hope will return something meaningful for all string_types we care of.

That sounds like a good idea.

[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.