std::reverse is available in the algorithm header and available everywhere. See https://en.cppreference.com/w/cpp/algorithm/reverse.
This function is not necessary.

Originally posted by @burgholzer in #6 (comment)

At the moment the graphical editor is functional, yet not very user-friendly and pretty. The following represents a non-complete list of possible improvements:

• The UI is not really responsive, e.g., the circuit that is displayed should, in general, fit the display area as a whole and not be cut off. The editor should also resize appropriately to fit its content.
• The Log Messages sub-element can be moved around arbitrarily. It would be great if this was also possible for the circuit view.
• The costs window can easily be integrated into the main UI by making the Log Messages Window smaller.
• Cost calculation should probably always be performed in combination with synthesis, since it takes practically no time and provides useful information. This also fits nicely with integrating this information directly in the UI.
• In a similar fashion, the statistics about the resulting circuit should most probably also include what is currently printed to the console: number of lines, inputs, constants, outputs, garbage values.
• The simulation result could/should also be integrated into the main UI. It could be placed instead/besides of the Log Messages since they do not occur that often.
• The simulation result does not look very appealing and is hard to read in general. there is definitely a way to format this in a nicer fashion (grouping of signal variables, spacing between in and out, removal or summary of const_0 inputs, etc.)
• On the implementation side, it is rather inefficient to synthesize the circuit again for the simulation and the calculation of the cost. If a circuit has already been synthesized, the resulting circuit can be used for the simulation. if a new circuit shall be simulated, it first has to be synthesized anyway.

Each of these task can be a separate pull request and any further feedback is welcome!

Editable installs of the project are currently broken with recent versions of setuptools [(>=64)]

The following PR tries to work around that issue.

https://github.com/cda-tum/qcec/pull/112

The error message is as follows:

raise DistutilsFileError(
distutils.errors.DistutilsFileError: can't copy '/tmp/tmpj41k2l6r.build-lib/pysyrec.cpython-38-x86_64-linux-gnu.so': doesn't exist or not a regular file
error: Support for editable installs via PEP 660 was recently introduced
in setuptools. If you are seeing this error, please report to:

  https://github.com/pypa/setuptools/issues

  Meanwhile you can try the legacy behavior by setting an
  environment variable and trying to install again:

  SETUPTOOLS_ENABLE_FEATURES="legacy-editable"
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building editable for mqt.syrec
Failed to build mqt.syrec

At the moment, the project still relies on Boost for some parts. Since Boost causes all kinds of troubles for deploying packages and getting libraries to run on different machines, it would be great to get rid of this dependency entirely.

In particular, this concerns:

• dynamic_bitset in https://github.com/cda-tum/syrec/blob/main/include/algorithms/simulation/simple_simulation.hpp. This can easily be replaced with std::vector<bool>. This also concerns dynamic_bitset in https://github.com/cda-tum/syrec/blob/main/mqt/syrec/bindings.cpp. std::vector<bool> should be automatically available in the Python bindings. maybe some convenience functions need to be provided.
• adjacency_list in https://github.com/cda-tum/syrec/blob/main/include/algorithms/synthesis/syrec_synthesis.hpp. This most certainly requires some rewriting of the synthesis method or re-implementing the adjacency_list functionality
• signal in https://github.com/cda-tum/syrec/blob/main/include/core/circuit.hpp. This is used for signalling during synthesis. Probably requires some rewriting of the synthesis function which can/should be combined with the previous task.
• The whole SyReC grammar and parser is written using boost::fusion and boost::spirit. It will take some time to rewrite this without using Boost, but should in principle be straight-forward.

After all these changes have been incorporated, all the workflows in https://github.com/cda-tum/syrec/tree/main/.github/workflows and https://github.com/cda-tum/syrec/blob/main/pyproject.toml can be alleviated of the Boost dependency.

At the moment, the SyReC library uses its own gate and circuit class. However, the project readily build upon our QFR library (mainly for the external dependencies). It should be rather straight-forward to replace the SyReC classes with the respective Operations (Toffoli's are just multi-controlled X gates, Fredkin gates are multi-controlled SWAP gates).

The QFR library also already features a .real file parser. At the moment this does not handle constant and garbage values properly (see cda-tum/mqt-core#88). However, this should be easy to fix.

The simulation routine should be straight-forward to adapt as well.

I also see no real obstacle for the synthesis method to be refactored to use the QFR library.

One major change considers the Python bindings. At the moment, the QFR library does not provide Python bindings for the QuantumComputation class (see cda-tum/mqt-core#89). This is most certainly required for refactoring the SyReC-editor.

It might be required to get rid of some of the Boost dependencies first (see #27), such as the dependency on boost::signal2.