My "Pointers tutorial" PDF resurrected

Discussion in 'C++' started by Alf P. Steinbach, Jun 18, 2010.


    Or you can find a clickable link in the right margin (in "PageLinks") at my blog.

    This document, evidently written in 2005, once created an extreme amount of
    traffic to my homepage, after someone mentioned it on [], and it was
    linked to (perhaps it's still linked to, but then that link is very broken!) in
    the Wikipedia article on pointers. Before that it created a number of discussion
    threads in this newsgroup, including one asking where to find it. The
    acknowledgements at the end of the document mentions quite a few denizens of
    this group who contributed, but that doesn't mean that everything in the
    document was peer-reviewed: as I recall only the first few sections were
    commented on.

    Note that there *is* a table of contents, but it's not presented by Google Docs.

    To see the TOC, view the document in e.g. Foxit (or Adobe Acrobat).

    Cheers, & enjoy!,

    - Alf

    blog at <url:>
    Alf P. Steinbach, Jun 18, 2010
    1. Advertisements

  2. Alf P. Steinbach

    Öö Tiib Guest

    On 18 juuni, 22:06, "Alf P. Steinbach" <> wrote:

    Wow. I used whole morning reading it. 171 pages massively illustrated
    and lot of examples. You teach the details of pointer usage there
    well ... and all dangers to avoid and techniques of usage are also
    mentioned. However it feels bit too long so issues are mentioned far
    between. I would keep pointers to data and pointers to (member)
    functions discussed in separate works from each other. Also i would
    probably move 1.5 (serialization) into separate work as well.

    What i have seen is that the major problem with data pointer is that
    most do not understand their raw, anonymous, overly multi-purpose and
    dangerous nature. Native pointers have too little information
    (considering wide variety of usages) in them and so are dead unsafe.
    It seems to be unclear to people why to *avoid* using these:

    1) Is it good pointer or not? How to detect it? How to save my
    application from crashing when i dereference bad pointer?

    Gotcha! He-hee. This is impossible to detect or recover from in
    platform independent way. Code must be written in a way that such
    questions do not arise. How? Another ROFL. Keeping only good pointers
    or null pointers around often takes significant discipline and effort
    to achieve.

    2) How to detect storage type of pointed at object? Is it automatic?
    Is it static? Is it dynamic?

    Gotcha! Hi-hii. There are no platform independent ways to detect that.
    Code has to be such that it does ensure required storage type or does
    not depend on it (may never deallocate storage it did not allocate
    itself, may never cast away const qualifier for modifying something
    const, may never store pointer of external origin for later usage).
    Where code has both to allow different storage types and depends on
    such it is all on shoulders of programmer.

    3) Is it pointer to whole array or a single object or element of
    array? If array is involved then how to detect it is pointing past
    last element of array (before first element of array)?

    Gotcha! Ho-hoo. There are no ways to detect it. That must be again be
    known at places where it matters. Never do algebra with a pointer if
    you do not know everything about the array it points at. While Alf
    correctly says in his work that there are rarely reasons to use raw
    dynamic (or automatic) arrays in code, the static arrays are still
    used quite often in most code i have seen.

    4) Is it pointing at whole separate object or pointer to base class of
    more derived object or pointer to data member of bigger class?

    Gotcha! LMAO. Again there are only limited ways to detect some of it.
    RTTI helps a bit with polymorphism. RTTI also increases the size of
    objects in memory. Performance hungry often want to turn it off with
    compiler options (often RTTI is still available thanks to presence of
    virtual member functions).

    5) Aren't raw pointers quick? Do not i lose in performance by using
    templates that wrap them?

    Gotcha! Not even funny. After profiling tens of applications one will
    see that as rule the reason of performance losses are elsewhere.
    Biggest performance increase is usually gained by picking more
    efficient algorithm or by picking better suited (for the most time-
    consuming algorithm in real application) container type. Seriously
    complicated field data may become available YEARS LATER after first
    writing the code and application gaining popularity and so on.
    Someones "reinventing square wheel" code does not usually let to use
    generic, easily replaceable algorithms with it. Also such manual
    management is hard to replace with better suited container.

    So ... what most novices seem to need is (more likely) a guide how to
    *not* use raw pointers and how to *get rid of* and *refactor out*
    pointers from code that (without properly proven reasons) uses them.
    Öö Tiib, Jun 19, 2010
    1. Advertisements

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. Carl Prothman [MVP]

    Re: Open linked PDF-Files from a PDF-File

    Carl Prothman [MVP], Aug 9, 2003, in forum: ASP .Net
    Paul Kuebler
    Aug 12, 2003
  2. Paul Kuebler

    Open linked PDF-Files from a PDF-File

    Paul Kuebler, Aug 12, 2003, in forum: ASP .Net
    Carl Prothman [MVP]
    Aug 18, 2003
  3. resurrected modindex

    , Oct 27, 2007, in forum: Python
  4. Alf P. Steinbach
  5. Bill Kelly
    Bill Kelly
    Mar 5, 2004
  6. Ezra Zygmuntowicz

    RubyConf 05 Audio and Video files resurrected!

    Ezra Zygmuntowicz, Dec 1, 2005, in forum: Ruby
    Bil Kleb
    Dec 2, 2005
  7. Ricardo Pog
    Austin Ziegler
    Mar 26, 2008
  8. Sean Nakasone
    Farrel Lifson
    Apr 14, 2008