Summary: | Create a Ptr<> analogon to Ref<> | ||
---|---|---|---|
Product: | Eigen | Reporter: | Christoph Hertzberg <chtz> |
Component: | Core - general | Assignee: | Nobody <eigen.nobody> |
Status: | DECISIONNEEDED --- | ||
Severity: | Feature Request | CC: | chtz, gael.guennebaud, jacob.benoit.1 |
Priority: | Normal | ||
Version: | 3.3 (current stable) | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | 884 | ||
Bug Blocks: | 1608 |
Description
Christoph Hertzberg
2014-12-05 15:03:20 UTC
Overloading operator& is indeed not good practice. The following: Ptr<MatrixXd> A; A = M.block(...); through overloading Ptr::operator= would be confusing too. It is like the user forgotten something: Is it: *A = M.block(...); or: A = Ptr<>(M.block(...)); So I would rather enforce ctor calls. (In reply to Gael Guennebaud from comment #1) > A = Ptr<>(M.block(...)); That is less error-prone, indeed. Perhaps a static Eigen::ptr function would be good, to avoid having to re-type the template parameters every time. Ptr<MatrixXd, Stride<...> > A(X.block(...)); A = ptr(Y.block(...)); And we could add some kind of reInit(...) function, which accepts everything the constructor accepts: A.reInit(Z.block(...)); A.reInit(0); -- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/912. |