Support checking if two objects target the same thing

[kerim371]

Hi,

I'm looking for a way to compare objects. For example I want to know whether two groups are the same and reffered to the same file?

I think it used to be possible with ObjectInfo::getAddress() but it is deprecated for now.

[matz-e]

Hi, would it possible for you to just compare the Group::getId() between the two groups/objects?

[kerim371]

@matz-e unfortunately the same Group (or any object) stored in different variables gives different id

[alkino]

What is the good way to compare two objects with different ifs following you?

[kerim371]

@alkino there is two types of objects:

1. usually stored in file (File, Group, DataSet, Attribute)
2. other like DataSpace, DataType

For the File I think the best way is to compare whether the file is the same? Since HDF5 1.12.0 there is a function wich (relying on documentation and my test but not 100% sure) can be used to compare files: herr_t H5Fget_fileno (hid_t file_id, unsigned long *fnumber )
For older HDF5 versions probably we need to compare filenames wich is inefficient but I can't see another way.

For Group, DataSet and Attribute we may compare do they have the same address and if they do then also compare do they belong to the same file?
Here the problem is that retrieved address is a deprecated struct member of H5Oget_info1(). But I've found the question on HDF5 forum posted last year where author tells that it possible to use deprecated address.

For DataSpace we can compare the dimensionality. So there is no need to compare the address because usually (or always) DataSpace doesn't belong to any file.

And DataType already has overloaded == and != operators

[alkino]

I think, it's a bad idea, because we will never be sure. If it's not possible by design in hdf5, we will do bad things.

[kerim371]

@alkino lately I asked similar question on HDF5 forum and I think that this could be done via token.
Though I have not tested it yet

[ferdonline]

I consider operator== and != pretty low-level and, due to ref counting, it's important to assume they are different if the hid is different.
For the purpose you mention I suggest an explicit call, like object.isSame(other). Ideas?

[kerim371]

I don't have a solution but here are couple of things I would like to share.

1. We have many classes inherited from HighFive::Object, but not all of them could be stored in HDF5 container. For example Dataspace can't be stored in HDF5 file (as far as I know). Also DataType may belong or may not belong to hdf5 file. Only Dataset, Group and Attribute can't live outside file. Thus implementing == (or isSame) to check whether objects are equal in the sense of path inside file can't be done directly in Object as public method (probably as protected it is possible).
2. DataType already has overloaded operators == and != that checks whether datatypes are equal to each other or not.
3. HighFive supports getAdress while it is deprecated in HDF5. Now tokens are used. If we decide to implement something that compares objects in the sense of the equality of path then we probably need to change ObjectInfo class by adding token staff.
4. I don't see any profit from == operator if we use it as a check equality of id. It is not much painful to directly compare id as bool val = obj.getId() == other.getId();. But when comparing path we need to retrieve path and compare strings that is always slow.
5. Files can be compared with H5Fget_fileno(...) of hdf5 library if hdf5 version is higher or equal to 1.12 and if version is less than 1.12 then it can be done via object->getInfo->getFileNo

[1uc]

We should check for v3 if we want DataType to continue behave differently from the other HighFive::Objects.

[1uc]

For the rest of the ticket: there's simply more than one notion of equality and we only have one operator==. The advantage of comparing identities is that it's very clear. While comparing sameness is something I don't understand well enough to be sure its unambiguous. It might be better to wrap any missing features, like access to the token; and let users define what exactly they mean by same in their application.

[1uc]

I don't think we should change the behaviour in v3.