1. 28 Feb, 2018 1 commit
  2. 11 Jan, 2018 1 commit
  3. 24 Nov, 2017 1 commit
  4. 02 Nov, 2017 1 commit
    • Unknown's avatar
      Trivial typos · 0b3f44eb
      Unknown authored
      Non-user facing. 
      Found using `codespell -q 3`
      0b3f44eb
  5. 21 Sep, 2017 1 commit
    • Ansgar Burchardt's avatar
      correct stride in matrix example and test · a22dd2d1
      Ansgar Burchardt authored
      This also matches the Eigen example for the row-major case.
      
      This also enhances one of the tests to trigger a failure (and fixes it in the PR).  (This isn't really a flaw in pybind itself, but rather fixes wrong code in the test code and docs).
      a22dd2d1
  6. 13 Sep, 2017 1 commit
  7. 12 Sep, 2017 1 commit
  8. 07 Sep, 2017 1 commit
  9. 06 Sep, 2017 1 commit
  10. 04 Sep, 2017 1 commit
  11. 01 Sep, 2017 1 commit
  12. 30 Aug, 2017 1 commit
  13. 28 Aug, 2017 2 commits
  14. 25 Aug, 2017 2 commits
  15. 22 Aug, 2017 3 commits
  16. 20 Aug, 2017 1 commit
  17. 19 Aug, 2017 2 commits
    • Patrik Huber's avatar
      Fix typos in Eigen documentation · d265933d
      Patrik Huber authored
      Fixes one small variable name typo, and two instances where `py::arg().nocopy()` is used, where I think it should be `py::arg().noconvert()` instead. Probably `nocopy()` was the old/original name for it and then it was changed.
      d265933d
    • Jason Rhinelander's avatar
      Allow module-local classes to be loaded externally · 5e14aa6a
      Jason Rhinelander authored
      The main point of `py::module_local` is to make the C++ -> Python cast
      unique so that returning/casting a C++ instance is well-defined.
      Unfortunately it also makes loading unique, but this isn't particularly
      desirable: when an instance contains `Type` instance there's no reason
      it shouldn't be possible to pass that instance to a bound function
      taking a `Type` parameter, even if that function is in another module.
      
      This commit solves the issue by allowing foreign module (and global)
      type loaders have a chance to load the value if the local module loader
      fails.  The implementation here does this by storing a module-local
      loading function in a capsule in the python type, which we can then call
      if the local (and possibly global, if the local type is masking a global
      type) version doesn't work.
      5e14aa6a
  18. 17 Aug, 2017 1 commit
    • Jason Rhinelander's avatar
      Allow binding factory functions as constructors · 464d9896
      Jason Rhinelander authored
      This allows you to use:
      
          cls.def(py::init(&factory_function));
      
      where `factory_function` returns a pointer, holder, or value of the
      class type (or a derived type).  Various compile-time checks
      (static_asserts) are performed to ensure the function is valid, and
      various run-time type checks where necessary.
      
      Some other details of this feature:
      - The `py::init` name doesn't conflict with the templated no-argument
        `py::init<...>()`, but keeps the naming consistent: the existing
        templated, no-argument one wraps constructors, the no-template,
        function-argument one wraps factory functions.
      - If returning a CppClass (whether by value or pointer) when an CppAlias
        is required (i.e. python-side inheritance and a declared alias), a
        dynamic_cast to the alias is attempted (for the pointer version); if
        it fails, or if returned by value, an Alias(Class &&) constructor
        is invoked.  If this constructor doesn't exist, a runtime error occurs.
      - for holder returns when an alias is required, we try a dynamic_cast of
        the wrapped pointer to the alias to see if it is already an alias
        instance; if it isn't, we raise an error.
      - `py::init(class_factory, alias_factory)` is also available that takes
        two factories: the first is called when an alias is not needed, the
        second when it is.
      - Reimplement factory instance clearing.  The previous implementation
        failed under python-side multiple inheritance: *each* inherited
        type's factory init would clear the instance instead of only setting
        its own type value.  The new implementation here clears just the
        relevant value pointer.
      - dealloc is updated to explicitly set the leftover value pointer to
        nullptr and the `holder_constructed` flag to false so that it can be
        used to clear preallocated value without needing to rebuild the
        instance internals data.
      - Added various tests to test out new allocation/deallocation code.
      - With preallocation now done lazily, init factory holders can
        completely avoid the extra overhead of needing an extra
        allocation/deallocation.
      - Updated documentation to make factory constructors the default
        advanced constructor style.
      - If an `__init__` is called a second time, we have two choices: we can
        throw away the first instance, replacing it with the second; or we can
        ignore the second call.  The latter is slightly easier, so do that.
      464d9896
  19. 14 Aug, 2017 1 commit
    • Jason Rhinelander's avatar
      Compile with hidden visibility always; set via cmake property rather than compiler flag · 97aa54fe
      Jason Rhinelander authored
      This updates the compilation to always apply hidden visibility to
      resolve the issues with default visibility causing problems under debug
      compilations.  Moreover using the cmake property makes it easier for a
      caller to override if absolutely needed for some reason.
      
      For `pybind11_add_module` we use cmake to set the property; for the
      targets, we append to compilation option to non-MSVC compilers.
      97aa54fe
  20. 12 Aug, 2017 1 commit
    • Dean Moldovan's avatar
      Add support for boost::variant in C++11 mode · 7918bcc9
      Dean Moldovan authored
      In C++11 mode, `boost::apply_visitor` requires an explicit `result_type`.
      This also adds optional tests for `boost::variant` in C++11/14, if boost
      is available. In C++17 mode, `std::variant` is tested instead.
      7918bcc9
  21. 07 Aug, 2017 2 commits
  22. 05 Aug, 2017 1 commit
    • Jason Rhinelander's avatar
      Made module_local types take precedence over global types · 4b159230
      Jason Rhinelander authored
      Attempting to mix py::module_local and non-module_local classes results
      in some unexpected/undesirable behaviour:
      
      - if a class is registered non-local by some other module, a later
        attempt to register it locally fails.  It doesn't need to: it is
        perfectly acceptable for the local registration to simply override
        the external global registration.
      - going the other way (i.e. module `A` registers a type `T` locally,
        then `B` registers the same type `T` globally) causes a more serious
        issue: `A.T`'s constructors no longer work because the `self` argument
        gets converted to a `B.T`, which then fails to resolve.
      
      Changing the cast precedence to prefer local over global fixes this and
      makes it work more consistently, regardless of module load order.
      4b159230
  23. 04 Aug, 2017 1 commit
    • Jason Rhinelander's avatar
      Add py::module_local() attribute for module-local type bindings · 7437c695
      Jason Rhinelander authored
      This commit adds a `py::module_local` attribute that lets you confine a
      registered type to the module (more technically, the shared object) in
      which it is defined, by registering it with:
      
          py::class_<C>(m, "C", py::module_local())
      
      This will allow the same C++ class `C` to be registered in different
      modules with independent sets of class definitions.  On the Python side,
      two such types will be completely distinct; on the C++ side, the C++
      type resolves to a different Python type in each module.
      
      This applies `py::module_local` automatically to `stl_bind.h` bindings
      when the container value type looks like something global: i.e. when it
      is a converting type (for example, when binding a `std::vector<int>`),
      or when it is a registered type itself bound with `py::module_local`.
      This should help resolve potential future conflicts (e.g. if two
      completely unrelated modules both try to bind a `std::vector<int>`.
      Users can override the automatic selection by adding a
      `py::module_local()` or `py::module_local(false)`.
      
      Note that this does mildly break backwards compatibility: bound stl
      containers of basic types like `std::vector<int>` cannot be bound in one
      module and returned in a different module.  (This can be re-enabled with
      `py::module_local(false)` as described above, but with the potential for
      eventual load conflicts).
      7437c695
  24. 27 Jun, 2017 2 commits
  25. 25 Jun, 2017 1 commit
  26. 24 Jun, 2017 3 commits
  27. 15 Jun, 2017 1 commit
  28. 12 Jun, 2017 1 commit
    • Jason Rhinelander's avatar
      Support multiple inheritance from python · e45c2114
      Jason Rhinelander authored
      This commit allows multiple inheritance of pybind11 classes from
      Python, e.g.
      
          class MyType(Base1, Base2):
              def __init__(self):
                  Base1.__init__(self)
                  Base2.__init__(self)
      
      where Base1 and Base2 are pybind11-exported classes.
      
      This requires collapsing the various builtin base objects
      (pybind11_object_56, ...) introduced in 2.1 into a single
      pybind11_object of a fixed size; this fixed size object allocates enough
      space to contain either a simple object (one base class & small* holder
      instance), or a pointer to a new allocation that can contain an
      arbitrary number of base classes and holders, with holder size
      unrestricted.
      
      * "small" here means having a sizeof() of at most 2 pointers, which is
      enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2
      ptrs).
      
      To minimize the performance impact, this repurposes
      `internals::registered_types_py` to store a vector of pybind-registered
      base types.  For direct-use pybind types (e.g. the `PyA` for a C++ `A`)
      this is simply storing the same thing as before, but now in a vector;
      for Python-side inherited types, the map lets us avoid having to do a
      base class traversal as long as we've seen the class before.  The
      change to vector is needed for multiple inheritance: Python types
      inheriting from multiple registered bases have one entry per base.
      e45c2114
  29. 31 May, 2017 1 commit
  30. 29 May, 2017 1 commit
    • Dean Moldovan's avatar
      Replace PYBIND11_PLUGIN with PYBIND11_MODULE · 443ab594
      Dean Moldovan authored
      This commit also adds `doc()` to `object_api` as a shortcut for the
      `attr("__doc__")` accessor.
      
      The module macro changes from:
      ```c++
      PYBIND11_PLUGIN(example) {
          pybind11::module m("example", "pybind11 example plugin");
          m.def("add", [](int a, int b) { return a + b; });
          return m.ptr();
      }
      ```
      
      to:
      
      ```c++
      PYBIND11_MODULE(example, m) {
          m.doc() = "pybind11 example plugin";
          m.def("add", [](int a, int b) { return a + b; });
      }
      ```
      
      Using the old macro results in a deprecation warning. The warning
      actually points to the `pybind11_init` function (since attributes
      don't bind to macros), but the message should be quite clear:
      "PYBIND11_PLUGIN is deprecated, use PYBIND11_MODULE".
      443ab594
  31. 28 May, 2017 1 commit