Re: Good documentation on c/c++ pointers?

[mike808@users.sourceforge.net]

"Bryan J. Smith" <b.j.smith@ieee.org> wrote ..
> Why might we do this?  
> 
> Well, there are countless applications.  But largely so we can switch
> the value a variable returns without changing any memory.

We also use pointers so that we _don't_ have to put potentially large data structures on a stack to pass this information to some function (or "method" in OO-parlance).

For example, lets say I have a structure that consists of an integer length value and an array of characters, potentially MAX_INT in size. Well, every time I need to do something with this data, I don't want to have to pass the whole shebang around making copies and such (since parameters to function calls are passed by _value_). So, what I'll do is have a structure that contains my length integer and a _pointer_ to some big honkin' chunk of memory large enough to hold the current array of characters (aka a "string"). Then, since parameters are passed to functions (on the stack) by value (meaning their value is copied onto the stack), that means that if I want my function to alter the value of the variable being passed in, then I don't want to pass in the variable's value, I want to pass in a _pointer_ to that variable -- which doesn't change where the variable's value is stored in memory, but that the function can use to change it, thus changing something external to itself.

Alternatively, you could put down your chisel and stone tablets, and spend your brain-cycles working at a much higher level of abstraction with a "higher level"  language than C. C++ counts, I guess, but there are even better choices.

Perhaps Perl, Java, C#, VB, or Ruby are more to your liking. Any of those languages pretty much handle the low-level redirection aspect of pointers, and you can concentrate on the logic you are trying to implement, instead of tracking down pointers that don't point where you expect them.

The biggest cause of pointer-related errors in C programming (which is probably a significant portion of the overall errors in C programming) is due to the mis-use of "pointer arithmetic". This is where, because you _think_ you know how much memory is between two values, you can do dumb 5hit like take a pointer and simply add some integer number of pre-calculated bytes to it, and then use the new pointer value as if it really did point to what you thought it did.

This is a classic buffer overflow anti-pattern. To do this, you really need to let the compiler do the calculation for you in the first place, and in the second place, you also need to stop yourself from telling the compiler to calculate a nonsensical result (through bad code).

In Perl, pointers are first-class data types, and Perl is smart enough to remove the magical "pointer"-ness of a pointer variable if you do dumb 5hit like try to use it as an lvalue in a math operation. And Perl distinguishes between a pointer (created by the "address of" operator) and a "reference". A reference, you see, can be used to access the "referent", but doing so must adhere to the interface defined by the type (or class) of the referent.

In Java, all this pointer business is just swept under the rug and they pretend they don't exist at all by not having an "address of" operator. That is until you get a "null pointer exception". Which is a bit odd for a language that by definition is not supposed to have pointers. Except for, I guess, null ones?

Anyway, any of those languages will get you out of the business of tracking pointer use and keep you focused on writing code that works more than it doesn't.

mike/

Mike/

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.