Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
The full use case where I encountered this issue is when doing recursive
merging of a target YAML graph by an updated, overlapping sub-graph as follows:
void mergeToNode(YAML::Node source, YAML::Node target) {
if (source.Type() == YAML::NodeType::Map) {
for (YAML::Node::const_iterator i = source.begin(); i != source.end(); ++i)
mergeToNode(i->second, target[i->first]);
else // Missing support for sequence merging here etc.
target = source;
}
Here the problem is that target[i->first] doesn't do deep equality comparison
but the shallow internal node-pointer based one. Because of this, it never
finds the old branches of the target graph and ends up adding the data as
duplicate data instead of replacing the old data.
I'm new to YAML, if there's a way to do this kind of partial graph update
somehow in a nicer fashion, I'll be happy. I see there was some discussion on
YAML features (the '<<' notation) but that was missing from yaml-cpp apparently?
Original comment by iridian....@googlemail.com
on 2 Feb 2015 at 10:25
This is basically working-as-intended. yaml-cpp does identity comparisons so
you can build recursive data structures. However, you can lookup by a typed-key
with your own equality, and that will lookup via equality. E.g.
struct Foo { ... };
bool operator ==(const Foo& a, const Foo& b) { ... }
// define appropriate conversion operators as in the docs
Foo x = ....;
node[x] = ...;
This will look up any key that's equal to x according to the user-defined
equality.
Original comment by jbe...@gmail.com
on 3 Feb 2015 at 6:32
Is there an function that could be used to do deep-equality testing?
I feel like this functionality should be part of the library, because it's both
a generic concept and also requiring a user to implement that manually is
probably much more work than if it's implemented on the library side. Then
again, if there is not even scalar YAML::Node level equality operator, I guess
a deep-equality can't really be offered, which is a bummer.
For my actual use case, I just did some explicit checking for the "i->first"
type and things like target[i->first.as<string>()] to get around, but it's not
a generic solution.
Original comment by iridian....@googlemail.com
on 3 Feb 2015 at 6:52
I see you opened Issue 274 about this. Feel free to continue discussion there -
but this is unlikely.
Original comment by jbe...@gmail.com
on 3 Feb 2015 at 2:09
Original issue reported on code.google.com by
iridian....@googlemail.com
on 2 Feb 2015 at 10:15