Condor,
Sorry I haven’t been able to respond as much lately. Having a 1 month old baby eats up a good amount of my time. =) But let me see if I can help re-explain what Deyja said, just so you get the info a second time, perhaps explained in a slightly different fashion.
First, don’t let the naming convention confuse you. How he chose to name the variables has nothing to do with the functionality of those variables. And as we've seen from this discussion, the important thing is to remain consistent. He suggests using 'p' at the beginning of a variable name to denote a 'pointer', but then clearly forgets to use it when working with member variables of standard types. Either he "forgot" to use it or his own coding style does not use the 'p' on either member variables or pointers to standard data types. Those are the only logical reasons he might have for NOT using the 'p'. I, however, would have continued to use the 'p' for consistency.
As to what I suspect is your second question. When you define a class, you're describing a new data type which is a collection of data and behaviors. The data and behaviors cannot be separated from each other or from the class. Whenever you declare an instance of a class - that is, an object - the compiler allocates enough memory to hold the entire object, as well as some additional space necessary for the function table. This is true whether you allocate the object on the stack, or the heap.
Now, consider the following class:
class MyClass{ int m_MyInteger; char m_MyCharacter; char* m_pMyPointer;}
Whenever I create an instance of the above class, I will allocate roughly 9 bytes of memory. Why 9? Well, because the integer takes 4, the character takes 1, and the pointer to a character takes 4. Add them up, and that's 9 bytes of data to hold this class.
But wait? should the char* be 1 byte...after all a character is 1 byte? NO! m_pMyPointer is not a character. Its a pointer. A pointer must be large enough to hold an address - and on most modern machines, that's 4 bytes. The important thing to remember is that all of the above variables will be allocated...whether on the stack or on the heap.
Now...the 9 byte allocation is the same whether I create the above object on the stack or on the heap. So what's the difference then? Well, there is none. What the book was trying to say is simply that it's possible to have pointer variables inside of classes...in this case, m_pMyPointer is a variable which holds an address...a pointer, but in order for you to access it, you must also allocate the memory which it points to. By default it holds an invalid address in it, or if you're a good programmer you've initialized it to the value 0 or NULL. So just as you allocated memory to store the object, you must allocate memory to store the data pointed at by m_pMyPointer.
But wait...didn’t I allocate the memory for m_pMyPointer when I allocated the object? Yes...and no. What you allocated was the memory necessary to hold the address of the data. You did not allocate the space in memory where the data is actually going to be located. Remember, a pointer is just a variable which holds an address. But until you allocate some memory and store the address of that new memory in the pointer...its useless.
Most often pointer variables within classes are allocated in the constructor, as you can see in the book on page 242 lines 24-25. The equivalent here would be:
m_pMyPointer = new char;
Now m_pMyPointer holds a valid address and I can access it without worry. So keep in mind, when working with pointers you've got 2 components. The memory for the pointer, and the memory the pointer "points to". Putting pointers in classes DOES allocate the memory for the pointer. Putting pointers in classes does NOT allocate the memory the pointer points to...you must do that yourself in the constructor or in another function.
Cheers!
