Not yet perfect, but:

http://home.no.net/dubjai/win32cpptu...ters/ch_01.pdf
http://home.no.net/dubjai/win32cpptu...1_examples.zip

To access the table of contents, use the "Bookmarks" tab in Adobe
Acrobat.

Comments, corrections, praise, nits, etc., are still welcome!

1 Pointers.
1.1 Introduction to the basics.
1.1.1 How to obtain a pointer to a given object, and how to use that pointer.
1.1.2 The nullpointer value, valid and invalid pointers.
1.1.3 How to implement out-arguments by using pointers.
1.1.4 How to implement in-arguments by using pointers.
1.1.5 How to use C++ style references instead of C style pointers for arguments.
1.1.6 How to access main arguments.
1.1.7 Const-correctness for pointers and references.
1.2 Run-time polymorphism.
1.2.1 Polymorphism.
1.2.2 The concepts of data representations and linked data structures.
1.2.3 C-style polymorphism with simulated dynamic types (just one actual type).
1.2.4 Basic use of dynamic memory allocation & deallocation.
1.2.5 How to use function pointers to simulate dynamic types, C-style.
1.2.6 Using real types and inheritance for logical sub-types, mostly C-style.
1.2.7 Using vtables, mostly C-style (also a few words about abstract classes, etc.).
1.2.8 C++ virtual member functions.
1.2.9 C++ destructors and polymorphic delete.
1.3 Safety for dynamically allocated objects.
1.3.1 Object ownership and the C++ std::auto_ptr.
1.3.2 Exception safety for new: RAII and C++ constructors.
1.3.3 Ensure dynamic allocation by using C++ access specifiers & friendship.
1.3.4 An aside on wrapping boost::shared_ptr (a.k.a. std::tr1::shared_ptr).
1.3.5 Ensure that smart pointers are used, by overloading operator new.
1.3.6 Combat slicing by removing access to copy assignment.
1.3.7 Value copying problems & possible solutions.
1.3.8 Cloning as a solution to ownership and aliasing problems.
1.3.9 Intentional sharing as a solution to ownership and aliasing problems.
1.4 An introduction to exceptions.
1.4.1 How to generate and handle exceptions.
1.4.2 Exception usage example: conversion between numeric values and text.
1.4.3 Exceptions and pointers, including the concept of "hard" exceptions.
1.5 Basic serialization and de-serialization.
1.5.1 A serialization format for hierarchical data structures.
1.5.2 De-serialization: a simple non-OO recursive descent parser.
1.5.3 Serialization: a simple generator using intrusive OO code.
1.5.4 A generator using non-intrusive non-OO code (introducing C++ RTTI).
1.5.5 A generator using non-intrusive OO code (introducing the visitor pattern).
1.6 Notes on C++ inheritance as it pertains to pointers.
1.6.1 Passing Base/Derived-class pointers by reference.
1.6.2 The Liskov substitution principle (more about mutable/immutable).
1.6.3 Covariance, contravariance and invariance.
1.7 Closing words & acknowledgements.

Hi Alf P. Steinbach,

Your PDF looks very neat at first look. Just now I have downloaded your
PDF..

You could have given the summary about your work, the reason for the
work, what you expect from the readers etc..

Thanks

Gopal

[Followups set to acllcc++]

Alf P. Steinbach said:

> Not yet perfect, but:
>
> [..]

GhostView doesn't like it. It gave an error on every page I tried (ten or
so). Just blank pages.

Since I don't have (and don't want to have) Adobe Acrobat, I was unable to
review the document.

Not complaining - just letting you know.

* Richard Heathfield:
> [Followups set to acllcc++]
>
> Alf P. Steinbach said:
>
> > Not yet perfect, but:
> >
> > [..]
>
> GhostView doesn't like it. It gave an error on every page I tried (ten or
> so). Just blank pages.

It's generated with OpenOffice 2.0. I guess that's the problem with open
source... ;-) I've only used GhostView to look at PostScript, so I'm not
familiar with it's PDF functionality.


> Since I don't have (and don't want to have) Adobe Acrobat, I was unable to
> review the document.
>
> Not complaining - just letting you know.

I've not upgraded my Acrobat because the latest version insists on installing
a "Yahoo toolbar", whatever that is. The toolbar can't be deselected in the
list of items to install. But older versions are clean, AFAIK.

Anyway, thanks for that feedback,

- Alf

Alf P. Steinbach wrote:

> Not yet perfect, but:
>
> [..]
>
http://home.no.net/dubjai/win32cpptu...1_examples.zip
>
> To access the table of contents, use the "Bookmarks" tab in Adobe
> Acrobat.
>
> Comments, corrections, praise, nits, etc., are still welcome!
>
It has nothing to do with the pointer stuff, but this fragment from your
in_by_pointer.cpp

typedef std::vector<int> IntVector;
..
..
..
double sum = 0.0;
for( std::size_t i = 0; i < pNumbers->size(); ++i )
{
sum += pNumbers->at( i );
}

arises the question: What is the (most) correct type for the loop variable
in such a for-loop as above?

As std::vector<>.size() returns a std::vector<>::size_type, shouldn't this
be

double sum = 0.0;
for( IntVector::size_type i = 0; i < pNumbers->size(); ++i )
{
sum += pNumbers->at( i );
}

In my implementation std::vector<>::size_type is just a typedef for
std::size_t, but is this guaranteed?

On Thu, 08 Dec 2005 08:04:13 GMT, alfps (Alf P. Steinbach)
wrote:
>Not yet perfect, but:
> [..]
> [..]
>
>To access the table of contents, use the "Bookmarks" tab in Adobe
>Acrobat.
>
>Comments, corrections, praise, nits, etc., are still welcome!

First impression: This is not a tutorial but a book.
Second impression: This is not a book about pointers but a book about
various C/C++ styles, idioms and techiques.
The book includes:
- basic concepts - e.g. "Introduction to the basics"
- advanced concepts - e.g. "Using vtables"
- How-tos - e.g. "How to access main arguments"
- techiques- e.g. "Basic serialization"
- idioms - e.g. "RAII"
- etc.

While each chapter contains valuable information (and is written by a
competent author) the current organization makes it difficult to read
the book for the presumed target audience, beginners and intermediate
programmers. From the reader's point of view it is not clear if a
chapter contains absolut necessary basic information or special (and
currently incomprehensible) cases that can be defered. The book is not
written as step-by-step introduction from basic to advanced.
An alternative would be to present the chapters as 'items' in the
style of Meyers and Sutter. Each item could be labeled as 'basic',
'intermediate' or 'advanced' to guide the reader.


Some remarks to the 'pointer' part of the book. Although it is
mentioned in the text I would emphasize from the beginning that:

1. Pointers are typed: A pointer can only point to an object of one
type. The type is static, i.e. it cannot be changed (of course, you
need to separately explain pointers to void). Strictly speaking, there
is no 'pointer' in C/C++ only a 'pointer to T'.

2. A pointer is a physical _and_ a logical reference to an object of
type T. As you explain, a pointer is a physical refernce because it
contains the address in memory of the pointed-to object. But it is
also a logical refernce. The user can reference the pointed-to object
without ever knowing its physical address. This 'double-nature' makes
pointers so 'expressive'.

Best regards,
Roland Pibinger

* Georg Wenig:
> * Alf P. Steinbach:
> It has nothing to do with the pointer stuff, but this fragment from your
> in_by_pointer.cpp
>
> typedef std::vector<int> IntVector;
> .
> .
> .
> double sum = 0.0;
> for( std::size_t i = 0; i < pNumbers->size(); ++i )
> {
> sum += pNumbers->at( i );
> }
>
> arises the question: What is the (most) correct type for the loop variable
> in such a for-loop as above?

Any integral type that can represent the actual number of items... ;-)

std::size_t is convenient since it's an unsigned type, avoiding a possible
warning because the vector's size_type is also guaranteed an unsigned type.

It seems to me that the library designers wanted us to use a great deal of
effort and time in selecting custom, context-dependent weapons, when in all
practical situations we can simply use the common pistol (we have a
Norwegian saying, from a children's TV show, "the simplest is the pistol",
meaning, for any problem).


> As std::vector<>.size() returns a std::vector<>::size_type, shouldn't this
> be
>
> double sum = 0.0;
> for( IntVector::size_type i = 0; i < pNumbers->size(); ++i )
> {
> sum += pNumbers->at( i );
> }
>
> In my implementation std::vector<>::size_type is just a typedef for
> std::size_t, but is this guaranteed?

No, I don't think so.

What I recall, vaguely, is that a collection class' size_type comes from the
allocator's size_type, which for the default allocator is std::size_t, but
just looking at the standard now I don't see that connection mentioned.

* Roland Pibinger:
>
[snip]
> The book is not
> written as step-by-step introduction from basic to advanced.

It is.

There are some forward-references mentioned in passing, e.g. use of
the term "constructor".

But otherwise it's all one long brick by brick construction from
fundamentals up, definitions/explanations (and not the least important,
a problem showing the necessity) before use, always.


> Some remarks to the 'pointer' part of the book. Although it is
> mentioned in the text I would emphasize from the beginning that:
>
> 1. Pointers are typed: A pointer can only point to an object of one
> type. The type is static, i.e. it cannot be changed (of course, you
> need to separately explain pointers to void).

Pointers void are in section 1.3.5.

Alf P. Steinbach wrote:
[..]
> 1.6.1 Passing Base/Derived-class pointers by reference.
> 1.6.2 The Liskov substitution principle (more about mutable/immutable).
> 1.6.3 Covariance, contravariance and invariance.
> 1.7 Closing words & acknowledgements.
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

Section 1.3.8 and 1.3.9 talk about a clone solution that requires a
virtual clone function, and then states this as a problem with using a
clone solution.
However, you can use a clone solution that does not require the base
class to ahve a virtual clone function (or derived class having clone
function).
See following clone smart pointers:
http:://code.axter.com/copy_ptr.h
http:://code.axter.com/cow_ptr.h
http:://code.axter.com/clone_ptr.h

All above clone smart pointers do not require clone functions for the
target T type.

This section makes the comparison between using clone method and using
boost::shared_ptr method, but I didn't see it mention the real reason
why you might need a clone method over a boost::shared_ptr method, and
the pros of using a clone smart pointer over using a shared_ptr.
See following link for more info:
http://www.codeguru.com/Cpp/Cpp/algo...le.php/c10407/

* Roland Pibinger:
>
> Each item could be labeled as 'basic',
> 'intermediate' or 'advanced' to guide the reader.

For someone (a novice) who hasn't yet been indoctrinated in what
should be regarded as basic, intermediate or advanced, what matters,
as I see it, is the need for various things in practical programming,
and how difficult those things are to grasp given the foundations
already laid down.

Anyway, since the organization of this document is a brick-by-brick
build-up of knowledge and techniques it follows that its sections
not just are in order from basic to advanced, but provide a clear
cut definition (as opposed to feelings) of what's more advanced ;-).

I think a pre-conceived, emotionally and socially based categorization,
rather than one based on what must logically come first, is giving us a
host of students fresh out of college or university with gaping holes in
their education.

Cheers,

- Alf

* Axter:
>
> Section 1.3.8 and 1.3.9 talk about a clone solution that requires a
> virtual clone function, and then states this as a problem with using a
> clone solution.

Thanks. Could you provide a quote? I'd like to fix that because that
was not my intention.

Alf P. Steinbach wrote:
> * Axter:
> >
> > Section 1.3.8 and 1.3.9 talk about a clone solution that requires a
> > virtual clone function, and then states this as a problem with using a
> > clone solution.
>
> Thanks. Could you provide a quote? I'd like to fix that because that
> was not my intention.
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
The following is listed under 1.3.9
Problems with our clone-it! solution to the copying side-effect and
aliasing problems include
· More complicated implementation code than necessary.
· More awkward client code than necessary (dereferencing, calls to
clone).
· Algorithmic (not just operational) inefficiency.

Since the above is under section 1.3.9 (Intentional sharing as a
solution to ownership and aliasing problems), I'm assuming the above is
being used to justify using shareing method versus cloning method.

If you're making the comparison, I think you should also include COW
pointers which work like a clone pointer and a shared smart pointer put
together.

>From what I've read so far, the document looks pretty good, and I think
it will be a good reference document. (Good Job)

Alf P. Steinbach wrote:
[..]
>>
>
> No, I don't think so.
>
> What I recall, vaguely, is that a collection class' size_type comes from the
> allocator's size_type, which for the default allocator is std::size_t, but
> just looking at the standard now I don't see that connection mentioned.
>

My standard library implementation says in a comment that it
is guaranteed:

/**
* The size_type for the default allocator is guaranteed to be std::size_t
* by the C++ Standard, 20.4.1 [lib.default.allocator].
*/

So on this occasion you're formally correct, even if for more
complicated reasons; encouraging use of size_type seems clean
to me, though when I'm lazy I'll admit to using std::size_t.

-- James

On Thu, 08 Dec 2005 12:40:00 GMT, alfps (Alf P. Steinbach)
wrote:
>For someone (a novice) who hasn't yet been indoctrinated in what
>should be regarded as basic, intermediate or advanced, what matters,
>as I see it, is the need for various things in practical programming,
>and how difficult those things are to grasp given the foundations
>already laid down.
>
>Anyway, since the organization of this document is a brick-by-brick
>build-up of knowledge and techniques it follows that its sections
>not just are in order from basic to advanced, but provide a clear
>cut definition (as opposed to feelings) of what's more advanced ;-).

It would be interesting to hear the opinion of _real_ novices about
the comprehensibility of the text.

Best regards,
Roland Pibinger

Looking good.
Two ideas:

- An index or chapter overview.
- Include "formal" definitions as well.