New user self-registration is disabled due to spam. Please email eigen-core-team @ if you need an account.
Before reporting a bug, please make sure that your Eigen version is up-to-date!
Bug 912 - Create a Ptr<> analogon to Ref<>
Summary: Create a Ptr<> analogon to Ref<>
Alias: None
Product: Eigen
Classification: Unclassified
Component: Core - general (show other bugs)
Version: 3.3 (current stable)
Hardware: All All
: Normal Feature Request
Assignee: Nobody
Depends on: 884
Blocks: 3.x
  Show dependency treegraph
Reported: 2014-12-05 15:03 UTC by Christoph Hertzberg
Modified: 2019-02-19 09:37 UTC (History)
3 users (show)


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&
  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(...);


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:


Note You need to log in before you can comment on or make changes to this bug.