nlohmann/json

deserialise from `std::vector`

mlund opened this issue · 6 comments

mlund commented

I'm trying to read into a vector, but run into the following problem:

#include <vector>
#include <json.hpp>
void from_json(const nlohmann::json &j, std::vector<int> &v) { /* something */ }
int main() {
    nlohmann::json j; 
    std::vector<int> v1 = j; // compiles
    std::vector<int> v2;
    v2 = j; // does not compile
}

Implementing as adl_serializer does not seem to work. Any help is greatly appreciated!

mlund commented

Perhaps I should mention that int is used for the sake of clarity, and that it's replaced with a custom type in my use-case. Nonetheless, v1 compiles while v2 does not. Using v2 = j.get<decltype(v2)>(); solves the problem, albeit not that compact. I suspect this has to do with overloads from std initialisation(?)

I can reproduce this with clang version 6.0.0 (trunk 309129):

error: use of overloaded operator '=' is ambiguous (with operand types 'std::vector<int>' and 'nlohmann::json'
      (aka 'basic_json<>'))
    v2 = j; // does not compile
    ~~ ^ ~
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/vector:565:13: note: candidate function
    vector& operator=(vector&& __x)
            ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/vector:553:13: note: candidate function
    vector& operator=(const vector& __x);
            ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/vector:572:13: note: candidate function
    vector& operator=(initializer_list<value_type> __il)
            ^
1 error generated.
make: *** [t] Error 1

I hope @theodelrieu can help here.

Indeed, this happens when T has multiple operator= definitions. I don't think we can do anything about it, I personally always use get in such cases.

We should add an entry to the documentation explaining why this issue exists.
The feature is quite convenient, but code breaks when someone adds an operator= to a class.

By the way, there is no need to add from_json method for std::vector and STL-types, the library already implement those (not to mention that your method will never be called by the library).

Updated the documentation.