Link error when using find() on the latest commit

[dianambb]

I am working on the develop branch.

I have a class defining the Json field constants.

// Class defining Json Fields
class JsonFields {
    public:
        static constexpr const char* ID = "id";
};

I pass in the constant value into find which throws the link error.

void MyClass::check_fields(json::basic_json j) {
        // Throws link error
        if (j.find(JsonFields::ID) != json_parsed.end()) {
        ....
        }
 }

However it works if I wrap the name in std::forward eg
j.find(std::forward<std::string>(JsonFields::ID))

This worked in commit 1b1bd0e but is broken in later commits. The change that introduced this issue is commit 6c9a401 .

[gregmarr]

This should work too:

static std::string ID = "id";

This way also results in only a single allocation per run instead of an allocation every time that find is called (though the allocation itself will probably be skipped due to the small string optimization here, it may not for larger strings).

What is the link error?

[dianambb]

@gregmarr - C++ doesn't allow initialization of non-const members in line. The only way to initialize a string is to use char*. So the other option that will work to explicitly convert char* to string.

j.find(std::string(JsonFields::ID))

The link error is

Undefined symbols for architecture x86_64:
  "JsonFields::ID", referenced from:
      MyClass::check_fields(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>) in check_field_values.o
ld: symbol(s) not found for architecture x86_64

[gregmarr]

Did you try adding the const there?
I'm not sure why you'd get an unresolved external for that variable because of this change.

[dianambb]

Yes it still gives the same error.
I worked around this by creating the field names as static const string and setting their values in the cpp file.

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