|Summary:||Create a Ptr<> analogon to Ref<>|
|Product:||Eigen||Reporter:||Christoph Hertzberg <chtz>|
|Component:||Core - general||Assignee:||Nobody <eigen.nobody>|
|Severity:||Feature Request||CC:||chtz, gael.guennebaud, jacob.benoit.1|
|Version:||3.3 (current stable)|
|Bug Depends on:||884|
Description Christoph Hertzberg 2014-12-05 15:03:20 UTC
Ref<> (similar to Map) has the disadvantage that once initialized its reference can't be changed (without a placement-new hack). This is similar to C++ references. An idea is to add the analogon of a pointer, which can be uninitialized (a NULL pointer) or which can be re-initialized at any time. For reinitialization operator=(const DenseBase<...>&) can be overloaded. Alternatively, we could overload operator& for DirectAccess types to return a Ptr object. Ptr<MatrixXd> A = & M.block(...); // with overloaded operator& vs Ptr<MatrixXd> A = M.block(...); // without overloading But overloading & is very often causing trouble. For fixed sized Ptr<> objects, initialization by a Scalar* could be considered: Ptr<Matrix3d> B = data; To access the referenced data, operator* and operator-> can be overloaded. Furthermore, operator! and operator bool can be overloaded to check if the pointer is NULL or not.
Comment 1 Gael Guennebaud 2014-12-05 18:10:19 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.
Comment 2 Christoph Hertzberg 2014-12-05 18:37:00 UTC
(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);
Comment 3 Nobody 2019-12-04 13:56:16 UTC
-- 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.