Arduino C++ Pointers

Maybe it is just me, but I had a hard time getting the idea of pointers through my thick skull. A few fine tutorials addressed some of my confusion but left me with a lot of questions. My “C - A Reference Manual” by Harbison and Steele provided the facts, and it only took them 1/2 page. This is great for reference but terrible for learning.

I knew that I wouldn’t understand this subject until I could explain it to others. This article is the result.

Although reviewed by “experts,” some may find errors while others won’t like my programming style. I look forward to their insights.

If you are interested, please, click here.


Your comments are welcome. All of us are smarter than any one of us.


Thanks,

Rick

Wow Rick, 23 pages...

Did I find errors? No.

Did I find you needed 23 pages? No. I'll explain that later.

Did I find it confusing? Yup, and I have a lot of code under my belt.

Where to start... First - lets simplify.

A variable is some value that you want to store and maybe change. A variable takes memory and except for special circumstances, you don't care where it is stored. The compiler takes care of that. In addition to where it is stored, the variable has type information - it might be a character, an integer, a floating point number, or something else (a structure, a string, an array of variables, an array of pointers to arrays, etc). You only need to worry about how many physical storage units a variable might take if you need to pass the variable to something that might work on it. If you have a variable that is global, then everywhere you use it (provided you have defined it correctly) the compiler will take care of the variable for you. Unless there is some reason that you need to know the details of a variable, and most of time the answer is no you don't, ignore how many bytes a variable might be.

A pointer is something that points to a variable. The pointer is effectively the address of a variable.

Why do we have pointers? In some cases, we want to pass the address of a vaiable to a function so that it can act on the variable and maybe modify the variable. In other cases, we might have an array or a structure (a number of variables grouped together), and it is simpler to pass the address of the array or structure rather than pass all the members of the array or structure. Another reason to pass a pointer would be if the function needs to operate on the array or structure and store the result back in the array or structure.

There - we have defined the two things - a variable and the pointer to the variable.

Everything beyond that is getting into the weeds for your simple C code (yes, it is just C code and while a C++ compiler will accept the code, you haven't done anything more than C - both Harbison & Steele (3rd edition - 1991 - on my shelf) and K&R (2nd edition -1988 - on my shelf) has the explainations for variables and pointers. Knowing where something is in memory is not important except in special cases and even then, if you have written your code well, you don't worry ever about where it is stored as it has been defined. This is one of the confusing parts that you should let go of. I realize this is a hardware forum and you are a hardware guy, but knowledge of where something is stored is not useful. Seriously, you don't need to know where or how it is stored. Knowing how to access the variable is what is useful.

Next is the concept of multiple programs accessing the data or passing variables between programs. I don't think you have multiple programs running that talk to each other. At the level of programming you are at, you have multiple functions. That's a good thing, but they are not programs - they are functions. Your local functions are not programs. Your program might refer to system functions (like printf or getc, etc.), but those are functions that are linked into your code in most cases. If you were actually passing information between programs, the mechanisim is much more complicated (protected spaces, etc.). Calling function Programs is very confusing.

You started out putting a space between the * and the variable and by page 8, this went away. Watch your style and be consistant. The * or & is not an operation, so white space might be confusing.

Also, you can't assume that an integer is always 2 bytes (p10), it might be different on a different cpu.

You learned something and that is good. You have a grasp on pointers, but direct manipulation of variables through pointers can be very dangerous.

Thanks for your detailed answer. I fixed my error related to saying programs and the number of bytes used for integers. I put C++ in the title because most of my references talked about C++. Yet my C book covers all of it so I agree with you and have removed ++ from the text.

As I understand it, * and & are instructions to the compiler. As such, blanks are ignored. I intensionally showed one with a blank and one without so I could explain this (bottom of page 7).

You told me volumes about yourself with "I have a lot of code under my belt." I have no doubt that this material is all second nature to you and you see it in the vast context of the entire language plus countless applications you have written. That is the reason you find what I have written confusing and, dare I say, painfully obvious. It is the flip side of why I read my book on C and C++ and find them confusing.

Thanks for your help. The updated article has you in the acknowledgment section.

Rick

I am sorry I came off as arrogant, that was not my intent.

You stated that you wouldn’t understand this subject until you could explain it to others. I am one of those others. With my experience, it was confusing to follow. Not because the material is second nature to me, but rather because of how you presented it. If I had a hard time following, then I could imagine someone who didn't know what the subject was would find it more difficult to follow along. Simply that and nothing more.

You said you understood * and & as being are instructions to the compiler. Technically, X=X+1 is an instruction to the compiler, but that is not what someone would call it. Both * and & are part of the C language just like ++ == &= and a bunch of others.

* is known as the indirection operator
& is known as the address of operator

* is also known as the multiplication operator
& is also known as the bitwise AND operator

How do we distinguish between the first * operator and the second * operator? We do so in the context of the language. It is recommended practice to put the * next to the variable name with no whitespace when we want to use it as an indirection operator, so that the human reader will recognize indirection. It is recommended to put whitespace around the * when we use if for multiplication. For example:

*X means indirection
2 * Y means multiplication

And for the & we do it as:

&Y means address of Y
Y & 0x0A means to bitwise AND of Y with the value in binary of 1010 which we could also write as 0x0A & Y

I mentioned style before and this is style is not your personal style, but the language style and if you write as the language style is set, then other humans can follow your style and it is less confusing. The compiler can be very forgiving on style, the human brain far less so.

Yes, I didn't understand pointers until I could explain them to others. I did not mean to imply that "others" would comprehend my explanation ;-)

Is my explanation useful? As the author, I am least qualified to judge. Only my target audience can say. I was aiming at people that are not far from running "Hello world" for the first time but who have some hardware background.

I greatly appreciate your insights on how to delineate * and & with the use of blank spaces around them. It makes all kinds of sense. As I look in my books, I consistently see blanks used around * and & as you show but I had not seen an explicit statement of why.

Your comment about pointers being just C and not C++ turned a light on for me. I kept looking for C++ books to help me understand this material and it was over my head. Once I realized that C was appropriate, I pulled out my very old books on it. I have "The C Programming Language" by Kernighan and Ritchie (1978), "C Notes" by Zahn (1979), and "The C Programmer's Handbook" by Bolsky (1985). I know these are dated but I have Harbison and Steele as a check. I also have "The Elements of Programming Style" by Kernighan and Plauger, Second Edition (1978) which contains the brilliant advice for all programmers: "Write clearly - don't be too clever."

I'll update the article again and publish it.

Thanks,

Rick