1. 07 Dec, 2016 1 commit
  2. 03 Dec, 2016 3 commits
    • Dean Moldovan's avatar
      Use C++14 index_sequence when possible · 8c85a857
      Dean Moldovan authored
      Newer standard libraries use compiler intrinsics for std::index_sequence
      which makes it ‘free’. This prevents hitting instantiation limits for
      recursive templates (-ftemplate-depth).
      8c85a857
    • Dean Moldovan's avatar
      Accept any sequence type as std::tuple or std::pair · 107285b3
      Dean Moldovan authored
      This is more Pythonic and compliments the std::vector and std::list
      casters which also accept sequences.
      107285b3
    • Dean Moldovan's avatar
      Split up tuple caster and function argument loader · 719c1733
      Dean Moldovan authored
      This is needed in order to allow the tuple caster to accept any sequence
      while keeping the argument loader fast. There is also very little overlap
      between the two classes which makes the separation clean. It’s also good
      practice not to have completely new functionality in a specialization.
      719c1733
  3. 01 Dec, 2016 2 commits
  4. 25 Nov, 2016 3 commits
  5. 24 Nov, 2016 4 commits
  6. 22 Nov, 2016 5 commits
  7. 20 Nov, 2016 6 commits
  8. 17 Nov, 2016 6 commits
    • Wenzel Jakob's avatar
      make arithmetic operators of enum_ optional (#508) · 405f6d1d
      Wenzel Jakob authored
      Following commit 90d278, the object code generated by the python
      bindings of nanogui (github.com/wjakob/nanogui) went up by a whopping
      12%. It turns out that that project has quite a few enums where we don't
      really care about arithmetic operators.
      
      This commit thus partially reverts the effects of #503 by introducing
      an additional attribute py::arithmetic() that must be specified if the
      arithmetic operators are desired.
      405f6d1d
    • Lori A. Burns's avatar
    • Dean Moldovan's avatar
      Improve consistency of array and array_t with regard to other pytypes · 4de27102
      Dean Moldovan authored
      * `array_t(const object &)` now throws on error
      * `array_t::ensure()` is intended for casters —- old constructor is
        deprecated
      * `array` and `array_t` get default constructors (empty array)
      * `array` gets a converting constructor
      * `py::isinstance<array_T<T>>()` checks the type (but not flags)
      
      There is only one special thing which must remain: `array_t` gets
      its own `type_caster` specialization which uses `ensure` instead
      of a simple check.
      4de27102
    • Dean Moldovan's avatar
      Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts · c7ac16bb
      Dean Moldovan authored
      The pytype converting constructors are convenient and safe for user
      code, but for library internals the additional type checks and possible
      conversions are sometimes not desired. `reinterpret_borrow<T>()` and
      `reinterpret_steal<T>()` serve as the low-level unsafe counterparts
      of `cast<T>()`.
      
      This deprecates the `object(handle, bool)` constructor.
      
      Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing
      warnings on MSVC.
      c7ac16bb
    • Dean Moldovan's avatar
      Add default and converting constructors for all concrete Python types · e18bc02f
      Dean Moldovan authored
      * Deprecate the `py::object::str()` member function since `py::str(obj)`
        is now equivalent and preferred
      
      * Make `py::repr()` a free function
      
      * Make sure obj.cast<T>() works as expected when T is a Python type
      
      `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert
      the given object to a different Python type. However, `obj.cast<T>()`
      usually calls `type_caster::load()` which only checks the type without
      doing any actual conversion. That causes a very unexpected `cast_error`.
      This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same
      when T is a Python type.
      
      * Simplify pytypes converting constructor implementation
      
      It's not necessary to maintain a full set of converting constructors
      and assignment operators + const& and &&. A single converting const&
      constructor will work and there is no impact on binary size. On the
      other hand, the conversion functions can be significantly simplified.
      e18bc02f
    • Dean Moldovan's avatar
      Add py::isinstance<T>(obj) for generalized Python type checking · b4498ef4
      Dean Moldovan authored
      Allows checking the Python types before creating an object instead of
      after. For example:
      ```c++
      auto l = list(ptr, true);
      if (l.check())
         // ...
      ```
      The above is replaced with:
      ```c++
      if (isinstance<list>(ptr)) {
          auto l = reinterpret_borrow(ptr);
          // ...
      }
      ```
      
      This deprecates `py::object::check()`. `py::isinstance()` covers the
      same use case, but it can also check for user-defined types:
      ```c++
      class Pet { ... };
      py::class_<Pet>(...);
      
      m.def("is_pet", [](py::object obj) {
          return py::isinstance<Pet>(obj); // works as expected
      });
      ```
      b4498ef4
  9. 16 Nov, 2016 4 commits
  10. 15 Nov, 2016 5 commits
    • Jason Rhinelander's avatar
      2e76daa5
    • Ivan Smirnov's avatar
      Add type casters for nullopt_t, fix none refcount (#499) · 425b4970
      Ivan Smirnov authored
      * Incref returned None in std::optional type caster
      
      * Add type casters for nullopt_t
      
      * Add a test for nullopt_t
      425b4970
    • Alexander Stukowski's avatar
      Provide more control over automatic generation of docstrings (#486) · 9a110e6d
      Alexander Stukowski authored
      Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
      9a110e6d
    • Jason Rhinelander's avatar
      Fix stl_bind to support movable, non-copyable value types (#490) · 617fbcfc
      Jason Rhinelander authored
      This commit includes the following changes:
      
      * Don't provide make_copy_constructor for non-copyable container
      
      make_copy_constructor currently fails for various stl containers (e.g.
      std::vector, std::unordered_map, std::deque, etc.) when the container's
      value type (e.g. the "T" or the std::pair<K,T> for a map) is
      non-copyable.  This adds an override that, for types that look like
      containers, also requires that the value_type be copyable.
      
      * stl_bind.h: make bind_{vector,map} work for non-copy-constructible types
      
      Most stl_bind modifiers require copying, so if the type isn't copy
      constructible, we provide a read-only interface instead.
      
      In practice, this means that if the type is non-copyable, it will be,
      for all intents and purposes, read-only from the Python side (but
      currently it simply fails to compile with such a container).
      
      It is still possible for the caller to provide an interface manually
      (by defining methods on the returned class_ object), but this isn't
      something stl_bind can handle because the C++ code to construct values
      is going to be highly dependent on the container value_type.
      
      * stl_bind: copy only for arithmetic value types
      
      For non-primitive types, we may well be copying some complex type, when
      returning by reference is more appropriate.  This commit returns by
      internal reference for all but basic arithmetic types.
      
      * Return by reference whenever possible
      
      Only if we definitely can't--i.e. std::vector<bool>--because v[i]
      returns something that isn't a T& do we copy; for everything else, we
      return by reference.
      
      For the map case, we can always return by reference (at least for the
      default stl map/unordered_map).
      617fbcfc
    • Wenzel Jakob's avatar
      06bd27f5
  11. 13 Nov, 2016 1 commit