Documentary template pointer class suggestion: fast_ptr templatewrapper for raw pointers

Discussion in 'C++' started by Rudi Cilibrasi, Oct 31, 2011.

  1. 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
    Rudi Cilibrasi, Oct 31, 2011
    #1
    1. Advertising

  2. Rudi Cilibrasi

    Werner Guest

    On Oct 31, 6:44 pm, Rudi Cilibrasi <> 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
    Werner, Nov 1, 2011
    #2
    1. Advertising

  3. 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

    On Nov 1, 12:45 am, Werner <> wrote:
    > On Oct 31, 6:44 pm, Rudi Cilibrasi <> 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
    Rudi Cilibrasi, Nov 1, 2011
    #3
  4. Rudi Cilibrasi

    Werner Guest

    On Nov 1, 6:25 pm, Rudi Cilibrasi <> wrote:

    > 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
    Werner, Nov 2, 2011
    #4
  5. Rudi Cilibrasi

    Jorgen Grahn Guest

    Re: Documentary template pointer class suggestion: fast_ptrtemplate wrapper for raw pointers

    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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Nov 2, 2011
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. christopher diggins
    Replies:
    16
    Views:
    749
    Pete Becker
    May 4, 2005
  2. Vijai Kalyan
    Replies:
    4
    Views:
    704
    Vijai Kalyan
    Nov 8, 2005
  3. Replies:
    7
    Views:
    449
    Adam Nielsen
    Sep 28, 2007
  4. Hicham Mouline
    Replies:
    100
    Views:
    2,081
    Noah Roberts
    Aug 25, 2009
  5. A L
    Replies:
    1
    Views:
    510
    Alf P. Steinbach /Usenet
    Aug 25, 2010
Loading...

Share This Page