On Oct 31, 6:44*pm, Rudi Cilibrasi <cilib...@gmail.com> wrote:
> 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