My "Pointers tutorial" PDF resurrected

[Alf P. Steinbach]

https://docs.google.com/fileview?id=0B2oiI2reHOh4M2MzNzYwYzQtMGZkNC00NTljLWJiM2UtOGI0MmRkMTMyZGY4

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 [reddit.com], 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

 

[Öö Tiib]

https://docs.google.com/fileview?id=0B2oiI2reHOh4M2MzNzYwYzQtMGZkNC00...

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.