Documentary template pointer class suggestion: fast_ptr templatewrapper for raw pointers

[Rudi Cilibrasi]

Hi everybody,

I have been studying the great new features of C++11, and realized
that we now have three main smart pointer types that are recommended:
unique_ptr, shared_ptr, and weak_ptr. I then noticed that so-called
raw pointers are not actually useless despite all the smart pointer
options now available. For instance, "non-owning raw pointers" are
the most efficient choice in cases where we know that another object
is managing the pointer lifetime for us and we are just acting as
observers.

http://herbsutter.com/elements-of-modern-c-style/

My problem with the use of old-style raw pointer syntax is that it is
not orthogonal when compared to the other three recommended template
pointer types. It makes use of the overloaded * operator that can be
used for multiply. It seems to me that the same argument against
using 0 for nullptr can be applied to using * for raw pointers. Why
don't we add a simple template wrapper to represent raw pointers that
is called "fast_ptr" in order to provide an easy-to-read documentary
syntax for raw pointers that avoids explicit use of the *. We can
still support unary * for people that prefer it, but being able to
completely avoid the use of unary * seems like it would make the
syntax easier to read, understand, and maintain. Then it becomes
possible to do things like grep for all _ptr types in a program
following this discipline, and the choice of which pointer type is
appropriate becomes more explicit in each case.

I look forward to reading your feedback on this matter. Best regards,

Rudi Cilibrasi

 

[Werner]

For instance, "non-owning raw pointers" are
the most efficient choice in cases where we know that another object
is managing the pointer lifetime for us and we are just acting as
observers.

Another reason for wrapping these "associating" pointers, which
for me is a greater reason, is that one can at least force the
initialization behaviour to be consistent by giving the smart
pointer a default constructor, and forcing initialization of
the contained pointer to zero without needing to remember
to include it in the initializer list.

All said, the purpose of this would not be to get rid of
the unary * operator altogether, but merely to get rid
of the risk incurred as result of uninitialized pointer
members. I do have a class that wraps bald pointers, simply
for the purpose of initialization, and I have found that it
reduces risk of dangling pointers considerably (IMHO).

I have given my smart pointer the name AssocPtr, indicating
that it is purposed for association where ownership is not
wanted.

It can be argued that weak_ptr has this purpose, but weak_ptr
constrains one in the sense that one can only create a weak_ptr
from an existing shared pointer, and not from say - a reference (a
situation which I, at least, find often arises).

http://herbsutter.com/elements-of-modern-c-style/

My problem with the use of old-style raw pointer syntax is that it is
not orthogonal when compared to the other three recommended template
pointer types.  It makes use of the overloaded * operator that can be
used for multiply.  It seems to me that the same argument against
using 0 for nullptr can be applied to using * for raw pointers.  Why
don't we add a simple template wrapper to represent raw pointers that
is called "fast_ptr" in order to provide an easy-to-read documentary
syntax for raw pointers that avoids explicit use of the *.  We can
still support unary * for people that prefer it, but being able to
completely avoid the use of unary * seems like it would make the
syntax easier to read, understand, and maintain.  Then it becomes
possible to do things like grep for all _ptr types in a program
following this discipline, and the choice of which pointer type is
appropriate becomes more explicit in each case.

Don't like the name fast_ptr, but I like the idea of being able to
grep for pointers, as well as the orthogonality idea (you mean to say
(According to my understanding of "orthogonal") that currently it is
orthogonal (different), and that it should not be...).

Kind regards,

Werner

 

[Rudi Cilibrasi]

Hi Leigh and Werner,

Thank you both for the useful feedback. I also struggle with the name
"fast" as well as the other terms "raw" and "native" as well as the
new one
called "bald." It is with some measure of discomfort that I suggest
"old_ptr", "observing_ptr", "nonowning_ptr", or "simple_ptr" but I
guess they all may be more technically correct. I think "assoc_ptr"
is also appropriate. I wonder if there should be two different
template
forms: one that is uninitialized like normal raw pointers (useful for
maximum
optimization), and one that accepts a second argument to support the
valuable default-initialization behavior that Werner describes and I
myself have also used.

I wanted to mention also that Werner's problem with weak_ptr is the
same
one that I have run into: its inability to handle references.
In this sense as well as the greppability, raw pointers seem more
functional.

I agree wholeheartedly on the subjective nature of perceived
orthogonality
as we move toward a common construction of a consensus understanding.
I would
welcome more feedback on this issue and would especially like to see
other people's
template wrappers for raw pointers to compare and contrast. Best
regards,

Rudi

 

[Werner]

I agree wholeheartedly on the subjective nature of perceived
orthogonality
as we move toward a common construction of a consensus understanding.
I would
welcome more feedback on this issue and would especially like to see
other people's template wrappers for raw pointers to compare and contrast..

My code can be found here:

http://www.codepaste.net/pydbs8

You'll notice that I used Andrei Alexandrescu's idea of using non-
members for reset, release etc. I'm not so sure now whether it is
a good idea. I realize "now" that by defining those function in
the namespace (instead of class definition) they will at least
be visible in the enclosing namespace.

Regards,

Werner

 

[Jorgen Grahn]

On Tue, 2011-11-01, Rudi Cilibrasi wrote:

[more smart pointers]

I would
welcome more feedback on this issue and would especially like to see
other people's
template wrappers for raw pointers to compare and contrast.

Here is one data point: I use C++ a lot, but I have never used a smart
pointer. I feel that other C++ constructs (from references to
iterators to more specialized wrapper classes) take away much of the
pain of raw pointers -- at least in the kind of code I write.

/Jorgen