Already merged in v7, qubit index parameters are checked for validity against simulators' allocated qubit bounds, to prevent OpenCL segmentation fault errors from explicitly invalid arguments.
The content of this PR is to replace the public API parameter pattern "pointer, pointerLength" with std::vector.
After 5 years of holding out for the more C-like version of the interface, there's very little to be said in favor of "pointer, pointerLength" over std::vector, which effectively enforces bounds safety. To use a contiguous subset of a std::vector from user code space, one can still use the appropriate iterator-based std::vector constructor. This probably requires the system to create a copy of the subset, but at most this is likely fewer than 50 elements copied, typically more like 1 or 2 elements. The benefits of bounds-enforcement have been assessed to be far more important than the additional execution time overhead, if that overhead can even be detected.
I had loosely planned for v8 to shape up by end of calendar year, but I suspect that not much damage will be done by merging sooner, particular since the v7 commit history is obviously still available. The XACC plugin update is also ready-to-go, right here, with plans to open a PR for it once Qrack v8 is merged in the Qrack repository:
Qrack v8 makes two major changes to the API:
std::vector
.After 5 years of holding out for the more C-like version of the interface, there's very little to be said in favor of "pointer, pointerLength" over
std::vector
, which effectively enforces bounds safety. To use a contiguous subset of astd::vector
from user code space, one can still use the appropriate iterator-basedstd::vector
constructor. This probably requires the system to create a copy of the subset, but at most this is likely fewer than 50 elements copied, typically more like 1 or 2 elements. The benefits of bounds-enforcement have been assessed to be far more important than the additional execution time overhead, if that overhead can even be detected.I had loosely planned for v8 to shape up by end of calendar year, but I suspect that not much damage will be done by merging sooner, particular since the v7 commit history is obviously still available. The XACC plugin update is also ready-to-go, right here, with plans to open a PR for it once Qrack v8 is merged in the Qrack repository:
https://github.com/WrathfulSpatula/xacc/tree/qrack_8_api
If you need support in converting your user code to API v8, please don't hesitate to reach out with a GitHub issue on this repository!