On READ case: that would be a logic error, providing such functionality would create confusion. You reading a non existing object, and the side effect of this ‘read’ is to create an object with unknown properties.
If you have a justified case, do use the previously outlined method using HDF5™ CAPI call to check, then branch on outcome or use
h5::read(...) call, catch
h5::error::io::any or the more specific
h5::io::dataset::open and act on that.
On WRITE case this makes sense, since the intention is clear: to persist an object, all information is provided to make it happen. Indeed
h5::write considers this, and does the right thing.
Keep in mind that H5CPP is not to replace HDF5™ CAPI but to complement it by providing syntactic sugar, optimization layer for C++ objects, and compiler assistance for reflection. which is not possible from CAPI.
There was effort put into seamless integration: h5::fd_t, h5::ds_t, … are binary compatible with CAPI descriptors. While you can emphasis your action by
hid_t ds = static_cast<hid>( h5::ds_t ) expressions, in the default case it is not needed, the conversion will take place at compile time. This can be prevented by redefining conversion policy, as outlined in documentation – which is case of small teams/projects may not that useful.
Think of HDF5™ as a very efficient binary filesystem that is tuned for scientific computing, And H5CPP is an object database/persistence layered on top. Finally here is the link to H5Lexists CAPI call that helps you to achaive what you want.