1

I think this is a duplicated question as it is plenty of examples where users experience the picking of wrong function with the same name and different arguments by the compiler, but I am using an extarnal library that I am not allowed to modify, so I have to figure out how to solve this problem as a user.

I am using the Quantum++ library to simulate quantum circuits. It is header only. It has this class called QCircuit which has two methods with the same name, same number of arguments but different types:

QCircuit& CTRL_fan(const cmat& U,
                       idx ctrl,
                       const std::vector<idx>& target,
                       std::optional<idx> shift = std::nullopt,
                       std::optional<std::string> name = std::nullopt)

and

QCircuit& CTRL_fan(const cmat& U,
                       const std::vector<idx>& ctrl,
                       const std::vector<idx>& target,
                       std::optional<std::vector<idx>> shift = std::nullopt,
                       std::optional<std::string> name = std::nullopt)

I need to pick the second one in the following code:

    qpp::QCircuit qcirc(5);
    std::vector<int> ancilla = {0,1};
    std::vector<int> reg = {3,4};
    qcirc.CTRL_fan(qpp::gt.RY(0.3), ancilla, reg);

With this code, the compiler is picking the first function. Even VScode intellisense is complaining. Actually I even tried to modify the code inside Quantum++ but it did not work either (of course I cannot change the name to avoid the modification of the entire library).

The error message:

src/ansatz.cpp: In member function ‘void satoAnsatz::addToCircuit(qpp::QCircuit&, bool)’:
src/ansatz.cpp:36:19: error: no matching function for call to ‘qpp::QCircuit::CTRL_fan(qpp::cmat, std::vector<int>&, std::vector<int>&)’
   36 |     qcirc.CTRL_fan(qpp::gt.RY(0.3), ancilla, reg);
      |     ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/qpp.h:149,
                 from src/ansatz.hpp:7,
                 from src/ansatz.cpp:1:
include/classes/circuits/circuits.hpp:2092:15: note: candidate: ‘qpp::QCircuit& qpp::QCircuit::CTRL_fan(const cmat&, qpp::idx, const std::vector<long unsigned int>&, std::optional<long unsigned int>, std::optional<std::__cxx11::basic_string<char> >)’
 2092 |     QCircuit& CTRL_fan(const cmat& U, idx ctrl, const std::vector<idx>& target,
      |               ^~~~~~~~
include/classes/circuits/circuits.hpp:2092:43: note:   no known conversion for argument 2 from ‘std::vector<int>’ to ‘qpp::idx’ {aka  long unsigned int’}
 2092 |     QCircuit& CTRL_fan(const cmat& U, idx ctrl, const std::vector<idx>& target,
      |                                       ~~~~^~~~
include/classes/circuits/circuits.hpp:2190:15: note: candidate: ‘qpp::QCircuit& qpp::QCircuit::CTRL_fan(const cmat&, const std::vector<long unsigned int>&, const std::vector<long unsigned int>&, std::optional<std::vector<long unsigned int> >, std::optional<std::__cxx11::basic_string<char> >)’
 2190 |     QCircuit& CTRL_fan(const cmat& U, const std::vector<idx>& ctrl,
      |               ^~~~~~~~
include/classes/circuits/circuits.hpp:2190:63: note:   no known conversion for argument 2 from ‘std::vector<int>’ to ‘const std::vector<long unsigned int>&’
 2190 |     QCircuit& CTRL_fan(const cmat& U, const std::vector<idx>& ctrl,
Pete Becker
  • 74,985
  • 8
  • 76
  • 165
francler
  • 21
  • 2
  • 2
    What is `idx`?? – Jarod42 Aug 01 '23 at 12:48
  • 1
    It seems your `vector`s have the wrong type inside, `int` versus `long unsigned int` (`idx`?). – Jarod42 Aug 01 '23 at 12:50
  • I have just found the error thanks to your comment - after 2 hours. The problem is that idx is std::size_t, while I was using std::vector. It seems that the compiler privileges int in place of std::vector when using std::vector... I expected an automatic conversion. So, I solved the problem by using vectors of idx (aka std::size_t). – francler Aug 01 '23 at 12:51
  • 7
    There are no conversions between `std::vector` and `std::vector` – Jarod42 Aug 01 '23 at 12:52
  • Nothing is “privileged”—it’s just that neither function is **viable**, so it showed you each with the reason why not. – Davis Herring Aug 01 '23 at 13:52

0 Answers0