Closed echavarria-lrz closed 1 month ago
Maybe a follow-up question to the issue itself: Why do we need all these methods at all? Why isn't it possible to simply call
dev->QDMI_control_pack_qir(qirmod, frag);
Maybe I am just overlooking things, but what is the particular reason for the current setup?
Just as a matter of fact, the change suggested by @echavarria-lrz makes two different interfaces of QDMI necessary, one that is called by the tools—that is the one as it stands now—and a second one with the signatures without the device that is implemented by the backends. I just want to mention this and this is neither a reason for or against it.
Regarding @burgholzer 's suggestion: This is a question of what functions should be exposed via the interface. Right now the QDMI_Device
is defined in https://github.com/Munich-Quantum-Software-Stack/QDMI/blob/4d4d0dc7c8331f0b2dc43119f2da0a53d2a5c203/include/qdmi_internal.h#L113-L119, which I suppose should be kept internal. Perhaps this just makes the interface more C like when you pass the device to a function instead of invoking a function that is stored in a struct as a pointer.
Resolved by #61.
Why do we need the
QDMI_Device
in any of these routines? Shouldn't it be enough to have, for example, this:Instead of this:
https://github.com/Munich-Quantum-Software-Stack/QDMI/blob/9baf644040ae782f33e2d5f1b2dc71ea121ed76a/src/qdmi_stubs.c#L17