-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finding a value in an array #399
Comments
Just looking a bit more - I think I found it ;-) from json.hpp:
|
Yes, the documentation of
To find elements in an array, you can use |
What confused me was the silent returning of find() giving me end(). Naively I'd expect an error somehow. I'm still discovering your style but would an assert not be the better solution for newbies like me. Please enlighten, it'll help me understand better your design decisions. |
The design decisions are difficult, because we basically try to "merge" the behavior of a I understand that silently returning |
Should the semantics be changed to throw in this case? |
"The basic_json object represents a json object" is a precondition of calling this function. |
@gregmarr In similar issues where we mix the behavior of std::map and std::vector we have the range of
In this case, there is just a comment that when called on anything but an object, find will always behave as if nothing was found. As searching in an array is rather expensive, I tend to throw an exception in this case. |
I just ran into the same problem with size_type size() const noexcept for a string-element. I accidently took it for the length of the string. |
@pboettch This is also clearly documented. |
After some thinking I agree with you. find() and size() work as they should and my expectations were wrong. I even can explain what mislead me: The slogan: "What if json was part of modern C++?". I understood that json is trying to integrate as much as possible with std::-containers and algorithms, but no. It actually means what is says: how would we design json to be a container class in std::? Lite this. As all cases are documented and well described, one just has to learn it. As for all the other containers. You can close this "issue" from my point of view. I would have rather discussed this on a mailing list than in an issue. Thanks again for your work. |
I may be going against the consensus here, but for someone who does not read documentation unless I can't get API to work to my expectations, returning |
I don't see a major issue with allowing find on arrays. If there is a note regarding the complexity impact that would be nice. I am picturing a structure with maybe 2-10 items in it, each referencing some id, and upon each we want to see if it contains A little bit of this is my wish for more convenience methods in the standard so take it for what you will ✌️ Since json isn't an array nor a map having a perfect correspondence to one or the other depending on the subtype to me at least doesn't make a lot of sense. |
So basically this is what I wrote in #399 (comment):
Any more opinions? |
Keep it as it is? If you change find()-behavior on an array, why not change size()-behavior on a string? Find is for finding a json-object identified by a key (AFAIU), in an array of strings there are no keys. |
|
My remark comparing a possible size()-behavior change to a find()-behavior-change was to show, IMHO, the current design is correct. It is strict and defined as one should expect. I think my initial problem would have not appeared here if I had found an example of how to find a value in a json-array - for example in the README. |
Any of the associative containers (set, multiset, etc) are allowed conversion to a json array which do support find in their native type. Without allowing the ability to search once this type has been included then converted to an array it seems like a (albeit partial) lossy abstraction, instead this could be a additive abstraction which either gains or keeps equal the search method from the convertible types. Certainly either way leaving it with end being returned seems wrong. |
So throwing seems to be the best way to go. |
I don't insist on throwing. If Edit: In fact, if you go with the principle of least astonishment, if a user called as for size_t size = 0;
for(const auto& jj : my_json) {
size++;
}
return size; |
Good point. I use the semantics of the Container requirement: |
Letting tl;dr: STL doesn't implement |
@louwers |
@TurpentineDistillery D'oh! Thanks for pointing that out. Lets try that again: the STL does't implement a |
The find function is used quite frequently to check if a key is present in an object. Removing it would make that check quite cumbersome. |
On a related note, if the behavior of |
The more I think about it, I tend to leave everything as is. The semantics of The same holds true for |
Another thing: I totally forgot the table in https://nlohmann.github.io/json which lists the behavior of all combinations of member functions known from the STL and the different JSON value types. |
I'm late to the discussion, but I've also just burned myself on this. I agree with people who think that |
Changing the behavior now would be a breaking change, and I do not thing such a change would be for the better. |
After searching online for about 10 minutes, I still can't figure out how to determine if a JSON array contains an element.
prints
what do I do here? EDIT: here's my solution:
|
contains() always returns |
I started using
nlohmann::json
today (thanks for it) and I wanted to check whether a certain value is contained in an array: I usedfind()
. It compiled but it does not work.it gives
Reading json.hpp I saw that
find()
is often done with a key. What is the expected behavior of finding on an array?The text was updated successfully, but these errors were encountered: