This bugzilla service is closed. All entries have been migrated to

Bug 912

Summary: Create a Ptr<> analogon to Ref<>
Product: Eigen Reporter: Christoph Hertzberg <chtz>
Component: Core - generalAssignee: 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   
Bug Depends on: 884    
Bug Blocks: 1608    

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:

Comment 3 Nobody 2019-12-04 13:56:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to'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: