This bugzilla service is closed. All entries have been migrated to
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-12-04 13:56 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:

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:

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