-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[API breaking] Use polymorphic value type holder for manifolds and constraint sets #90
Conversation
6f83d1c
to
4f007fc
Compare
4d33d96
to
d026846
Compare
The last thing to do before merging, which is very relevant for downstream integration into aligator, is being able to extend interfaces from Python. Right now, inheriting from
|
031b3fa
to
2141f6a
Compare
fe0d337
to
94830ff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After quick glance, PR seems ok
While discussing with @jorisv, we found that:
|
a6ef49c
to
3308bfa
Compare
+ also remove anon-namespaced typedef PolymorphicManifold
…g-v2-rebased Topic/polymorphic binding v2 rebased
…orward ctor arguments
remove PointType and TangentVectorType typedefs (they're always dynamic sized arrays)
5231f3d
to
80601a0
Compare
Okay, we will be merging this today. This is not the perfect solution imo, I'd be willing to look at other types of type erasure in the future for the definitive API (and rip out the OOP class hierarchies here and in aligator, downstream). |
…c-value [API breaking] Use polymorphic value type holder for manifolds and constraint sets
This PR:
shared_ptr
for manifold and constraint set types, switching to jbcoe/value_types'spolymorphic
template class everywhere as a holder with value semanticsstd::make_shared<T>(...)
all the time, see changed C++ examplesproxsuite-nlp/python/polymorphic.hpp
for dealing with values/references ofpolymorphic<T>
, register conversions, etcPolymorphicVisitor
to the Python bindings which registers a typeY
as convertible to the template argumentpolymorphic<X>
constraints.txx
: closes Template instantiation: split upconstraints.hpp
andconstraints.txx
mega-headers #87Known issues
polymorphic<X>
by value does not check whether the underlying object is aboost::python::wrapper<U>
for some typeU
which inherits fromX
Background
This is the first in a series of PR which will cut down on our overuse of
shared_ptr
across both proxsuite-nlp and aligator and replace it with a holder for polymorphic objects with value semantics.The drawbacks to the current approach with
shared_ptr
was:shared_ptr<T>
, except if we add virtual clone member functions implemented in all derived classesBoxConstraint
)The polymorphic value type was described by Jonathan Coe: https://www.youtube.com/watch?v=sjLRX4WMvlU. It allows composite classes (with polymorphic data members) to behave well using value-semantics all the way down (with const-correctness).
Why not unique_ptr ?
unique_ptr completely removes any ability to copy the underlying object (except if a virtual
clone()
was implemented) and disables default copy ctor/operators for all composite classes using it.Many thanks to @edantec for his contribution.