For the project I'm currently working on, I need to write a custom driver.
Inheriting from hdf5::file::Driver works per se, but to overload the pure virtual function id() I need to return a hdf5::file::DriverID, which currently is limited to Posix, Direct, Memory, and MPI.
I could not find any reference to hdf5::file::DriverID other than the once in the existing drivers id() functions, so I'm not sure what the intended use id() is.
Would it be feasible to add another choice (e.g., Custom) to the hdf5::file::DriverID enum?
Alternatively, if the ID should remain unique even when multiple custom drivers are to be used, one might also consider some form of registration, that hands out unique integer ids for each driver. In any case I believe driver should be implemented as an open set, since hdf5 itself implements it that way. The implementation using the enum class makes this difficult, as it inherently makes it a closed set.
For the project I'm currently working on, I need to write a custom driver.
Inheriting from
hdf5::file::Driver
works per se, but to overload the pure virtual functionid()
I need to return ahdf5::file::DriverID
, which currently is limited toPosix
,Direct
,Memory
, andMPI
.I could not find any reference to
hdf5::file::DriverID
other than the once in the existing driversid()
functions, so I'm not sure what the intended useid()
is.Would it be feasible to add another choice (e.g.,
Custom
) to thehdf5::file::DriverID
enum?Alternatively, if the ID should remain unique even when multiple custom drivers are to be used, one might also consider some form of registration, that hands out unique integer ids for each driver. In any case I believe driver should be implemented as an open set, since hdf5 itself implements it that way. The implementation using the enum class makes this difficult, as it inherently makes it a closed set.