mirror of
https://github.com/pybind/pybind11.git
synced 2024-11-21 20:55:11 +00:00
Seamless operability between C++11 and Python
21282e645a
* Add make_value_iterator (#3271) * Add make_value_iterator This is the counterpart to make_key_iterator, and will allow implementing a `value` method in `bind_map` (although doing so is left for a subsequent PR). I made a few design changes to reduce copy-and-paste boilerplate. Previously detail::iterator_state had a boolean template parameter to indicate whether it was being used for make_iterator or make_key_iterator. I replaced the boolean with a class that determines how to dereference the iterator. This allows for a generic implementation of `__next__`. I also added the ValueType and Extra... parameters to the iterator_state template args, because I think it was a bug that they were missing: if make_iterator is called twice with different values of these, only the first set has effect (because the state class is only registered once). There is still a potential issue in that the *values* of the extra arguments are latched on the first call, but since most policies are empty classes this should be even less common. * Add some remove_cv_t to appease clang-tidy * Make iterator_access and friends take reference For some reason I'd accidentally made it take a const value, which caused some issues with third-party packages. * Another attempt to remove remove_cv_t from iterators Some of the return types were const (non-reference) types because of the pecularities of decltype: `decltype((*it).first)` is the *declared* type of the member of the pair, rather than the type of the expression. So if the reference type of the iterator is `pair<const int, int> &`, then the decltype is `const int`. Wrapping an extra set of parentheses to form `decltype(((*it).first))` would instead give `const int &`. This means that the existing make_key_iterator actually returns by value from `__next__`, rather than by reference. Since for mapping types, keys are always const, this probably hasn't been noticed, but it will affect make_value_iterator if the Python code tries to mutate the returned objects. I've changed things to use double parentheses so that make_iterator, make_key_iterator and make_value_iterator should now all return the reference type of the iterator. I'll still need to add a test for that; for now I'm just checking whether I can keep Clang-Tidy happy. * Add back some NOLINTNEXTLINE to appease Clang-Tidy This is favoured over using remove_cv_t because in some cases a const value return type is deliberate (particularly for Eigen). * Add a unit test for iterator referencing Ensure that make_iterator, make_key_iterator and make_value_iterator return references to the container elements, rather than copies. The test for make_key_iterator fails to compile on master, which gives me confidence that this branch has fixed it. * Make the iterator_access etc operator() const I'm actually a little surprised it compiled at all given that the operator() is called on a temporary, but I don't claim to fully understand all the different value types in C++11. * Attempt to work around compiler bugs https://godbolt.org/ shows an example where ICC gets the wrong result for a decltype used as the default for a template argument, and CI also showed problems with PGI. This is a shot in the dark to see if it fixes things. * Make a test constructor explicit (Clang-Tidy) * Fix unit test on GCC 4.8.5 It seems to require the arguments to the std::pair constructor to be implicitly convertible to the types in the pair, rather than just requiring is_constructible. * Remove DOXYGEN_SHOULD_SKIP_THIS guards Now that a complex decltype expression has been replaced by a simpler nested type, I'm hoping Doxygen will be able to build it without issues. * Add comment to explain iterator_state template params * fix: regression in #3271 Co-authored-by: Bruce Merry <1963944+bmerry@users.noreply.github.com> |
||
|---|---|---|
| .github | ||
| docs | ||
| include/pybind11 | ||
| pybind11 | ||
| tests | ||
| tools | ||
| .appveyor.yml | ||
| .clang-format | ||
| .clang-tidy | ||
| .cmake-format.yaml | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| .readthedocs.yml | ||
| CMakeLists.txt | ||
| LICENSE | ||
| MANIFEST.in | ||
| noxfile.py | ||
| pyproject.toml | ||
| README.rst | ||
| setup.cfg | ||
| setup.py | ||
.. figure:: https://github.com/pybind/pybind11/raw/master/docs/pybind11-logo.png :alt: pybind11 logo **pybind11 — Seamless operability between C++11 and Python** |Latest Documentation Status| |Stable Documentation Status| |Gitter chat| |GitHub Discussions| |CI| |Build status| |Repology| |PyPI package| |Conda-forge| |Python Versions| `Setuptools example <https://github.com/pybind/python_example>`_ • `Scikit-build example <https://github.com/pybind/scikit_build_example>`_ • `CMake example <https://github.com/pybind/cmake_example>`_ .. start **pybind11** is a lightweight header-only library that exposes C++ types in Python and vice versa, mainly to create Python bindings of existing C++ code. Its goals and syntax are similar to the excellent `Boost.Python <http://www.boost.org/doc/libs/1_58_0/libs/python/doc/>`_ library by David Abrahams: to minimize boilerplate code in traditional extension modules by inferring type information using compile-time introspection. The main issue with Boost.Python—and the reason for creating such a similar project—is Boost. Boost is an enormously large and complex suite of utility libraries that works with almost every C++ compiler in existence. This compatibility has its cost: arcane template tricks and workarounds are necessary to support the oldest and buggiest of compiler specimens. Now that C++11-compatible compilers are widely available, this heavy machinery has become an excessively large and unnecessary dependency. Think of this library as a tiny self-contained version of Boost.Python with everything stripped away that isn’t relevant for binding generation. Without comments, the core header files only require ~4K lines of code and depend on Python (2.7 or 3.5+, or PyPy) and the C++ standard library. This compact implementation was possible thanks to some of the new C++11 language features (specifically: tuples, lambda functions and variadic templates). Since its creation, this library has grown beyond Boost.Python in many ways, leading to dramatically simpler binding code in many common situations. Tutorial and reference documentation is provided at `pybind11.readthedocs.io <https://pybind11.readthedocs.io/en/latest>`_. A PDF version of the manual is available `here <https://pybind11.readthedocs.io/_/downloads/en/latest/pdf/>`_. And the source code is always available at `github.com/pybind/pybind11 <https://github.com/pybind/pybind11>`_. Core features ------------- pybind11 can map the following core C++ features to Python: - Functions accepting and returning custom data structures per value, reference, or pointer - Instance methods and static methods - Overloaded functions - Instance attributes and static attributes - Arbitrary exception types - Enumerations - Callbacks - Iterators and ranges - Custom operators - Single and multiple inheritance - STL data structures - Smart pointers with reference counting like ``std::shared_ptr`` - Internal references with correct reference counting - C++ classes with virtual (and pure virtual) methods can be extended in Python Goodies ------- In addition to the core functionality, pybind11 provides some extra goodies: - Python 2.7, 3.5+, and PyPy/PyPy3 7.3 are supported with an implementation-agnostic interface. - It is possible to bind C++11 lambda functions with captured variables. The lambda capture data is stored inside the resulting Python function object. - pybind11 uses C++11 move constructors and move assignment operators whenever possible to efficiently transfer custom data types. - It’s easy to expose the internal storage of custom data types through Pythons’ buffer protocols. This is handy e.g. for fast conversion between C++ matrix classes like Eigen and NumPy without expensive copy operations. - pybind11 can automatically vectorize functions so that they are transparently applied to all entries of one or more NumPy array arguments. - Python's slice-based access and assignment operations can be supported with just a few lines of code. - Everything is contained in just a few header files; there is no need to link against any additional libraries. - Binaries are generally smaller by a factor of at least 2 compared to equivalent bindings generated by Boost.Python. A recent pybind11 conversion of PyRosetta, an enormous Boost.Python binding project, `reported <http://graylab.jhu.edu/RosettaCon2016/PyRosetta-4.pdf>`_ a binary size reduction of **5.4x** and compile time reduction by **5.8x**. - Function signatures are precomputed at compile time (using ``constexpr``), leading to smaller binaries. - With little extra effort, C++ types can be pickled and unpickled similar to regular Python objects. Supported compilers ------------------- 1. Clang/LLVM 3.3 or newer (for Apple Xcode’s clang, this is 5.0.0 or newer) 2. GCC 4.8 or newer 3. Microsoft Visual Studio 2015 Update 3 or newer 4. Intel classic C++ compiler 18 or newer (ICC 20.2 tested in CI) 5. Cygwin/GCC (previously tested on 2.5.1) 6. NVCC (CUDA 11.0 tested in CI) 7. NVIDIA PGI (20.9 tested in CI) About ----- This project was created by `Wenzel Jakob <http://rgl.epfl.ch/people/wjakob>`_. Significant features and/or improvements to the code were contributed by Jonas Adler, Lori A. Burns, Sylvain Corlay, Eric Cousineau, Aaron Gokaslan, Ralf Grosse-Kunstleve, Trent Houliston, Axel Huebl, @hulucc, Yannick Jadoul, Sergey Lyskov Johan Mabille, Tomasz Miąsko, Dean Moldovan, Ben Pritchard, Jason Rhinelander, Boris Schäling, Pim Schellart, Henry Schreiner, Ivan Smirnov, Boris Staletic, and Patrick Stewart. We thank Google for a generous financial contribution to the continuous integration infrastructure used by this project. Contributing ~~~~~~~~~~~~ See the `contributing guide <https://github.com/pybind/pybind11/blob/master/.github/CONTRIBUTING.md>`_ for information on building and contributing to pybind11. License ~~~~~~~ pybind11 is provided under a BSD-style license that can be found in the `LICENSE <https://github.com/pybind/pybind11/blob/master/LICENSE>`_ file. By using, distributing, or contributing to this project, you agree to the terms and conditions of this license. .. |Latest Documentation Status| image:: https://readthedocs.org/projects/pybind11/badge?version=latest :target: http://pybind11.readthedocs.org/en/latest .. |Stable Documentation Status| image:: https://img.shields.io/badge/docs-stable-blue.svg :target: http://pybind11.readthedocs.org/en/stable .. |Gitter chat| image:: https://img.shields.io/gitter/room/gitterHQ/gitter.svg :target: https://gitter.im/pybind/Lobby .. |CI| image:: https://github.com/pybind/pybind11/workflows/CI/badge.svg :target: https://github.com/pybind/pybind11/actions .. |Build status| image:: https://ci.appveyor.com/api/projects/status/riaj54pn4h08xy40?svg=true :target: https://ci.appveyor.com/project/wjakob/pybind11 .. |PyPI package| image:: https://img.shields.io/pypi/v/pybind11.svg :target: https://pypi.org/project/pybind11/ .. |Conda-forge| image:: https://img.shields.io/conda/vn/conda-forge/pybind11.svg :target: https://github.com/conda-forge/pybind11-feedstock .. |Repology| image:: https://repology.org/badge/latest-versions/python:pybind11.svg :target: https://repology.org/project/python:pybind11/versions .. |Python Versions| image:: https://img.shields.io/pypi/pyversions/pybind11.svg :target: https://pypi.org/project/pybind11/ .. |GitHub Discussions| image:: https://img.shields.io/static/v1?label=Discussions&message=Ask&color=blue&logo=github :target: https://github.com/pybind/pybind11/discussions