|
I am writing an article about using pointers in order to demystify them.
The issue is they're instinct to me. They're not confusing, and it has been so long since they were that I don't know what people struggle with anymore. I mean, I've got plenty of things I've already covered - but they're the more obvious things, and I also don't know if I've covered every base.
So especially for those of you that haven't used them much, or are actively repelled by them, what about them (aside from the obvious dangers of directly manipulating memory) makes them awful for you?
To err is human. Fortune favors the monsters.
|
|
|
|
|
When I started with C more than 25 years ago, I was scared of double pointers; that scare still exists. So, if you can elucidate them with examples, that would be useful.
|
|
|
|
|
Good call. They are a little more difficult in concept because they are meta - an indirection of an indirection, but I think I can clarify them. Thanks!
To err is human. Fortune favors the monsters.
|
|
|
|
|
I'm not 100% sure (pointers are just .. normal .. to me too) but here are some things I've seen in people who struggled with them:
- Confusion between a variable and its value. If you think of a variable as being a value rather than having a value, pointers don't make sense.
- Having no down-to-earth view of what memory is. If you view it as a mystical black box where value are associated to variables by some unholy combination of the name of a variable and a particular function invocation or whatever (to be able to handle recursion), pointers don't make sense.
|
|
|
|
|
Around 40 years ago I was given a task at work, and (for good reasons) it needed to be written in C. I had no knowledge of C at the time, so I got hold of K&R's wonderful book and spent the weekend reading it. Coming from a machine code and assembler background, it was obvious what pointers were for, and why; so I have never had a problem with them*. But I think many developers these days lack that background, and I don't think they get taught about machine level stuff. So I think your article will be very welcome to many people.
*not strictly true but ...
|
|
|
|
|
Some things to consider mentioning are
|
|
|
|
|
Implement a 2D array (or 3D for bonus points) using pointers. By the end of that exercise, the user will understand pointers! I wish I still had that old code, but it looks like it's been deleted.
I second the double-indirection suggestion. Even understanding the concept, I'll probably always have to trial and error the syntax to get the code working right for some reason.
|
|
|
|
|
Quote: There is a subtle near-ambiguity in the C syntax for two-dimensional array
references. Let us elucidate it, and then turn it to our advantage. Consider the
array reference to a (say) float value a[i][j], where i and j are expressions
that evaluate to type int. A C compiler will emit quite different machine code for
this reference, depending on how the identifier a has been declared. If a has been
declared as a fixed-size array, e.g., float a[5][9], then the machine code is: “to
the address a add 9 times i, then add j, return the value thus addressed.” Notice that
the constant 9 needs to be known in order to effect the calculation, and an integer
multiplication is required (see Figure 1.2.1).
Suppose, on the other hand, that a has been declared by float **a. Then
the machine code for a[i][j] is: “to the address of a add i, take the value thus
addressed as a new address, add j to it, return the value addressed by this new
address.” Notice that the underlying size of a[][] does not enter this calculation
at all, and that there is no multiplication; an additional indirection replaces it. We
thus have, in general, a faster and more versatile scheme than the previous one. The
price that we pay is the storage requirement for one array of pointers (to the rows
of a[][]), and the slight inconvenience of remembering to initialize those pointers
when we declare an array.
Here is our bottom line: We avoid the fixed-size two-dimensional arrays of C as
being unsuitable data structures for representing matrices in scientific computing. We
adopt instead the convention “pointer to array of pointers,” with the array elements
pointing to the first element in the rows of each matrix.
("Numerical Receipes in C: The art of Scientific Computing" pag. 20)
Mircea
|
|
|
|
|
I don't think pointers per se are a problem; it's the (c++) syntax. Other languages have implicit support so you just don't have to "think" about it as much. Most people working in C# know what a "reference" is.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I am long time C programmer (not C++). I view pointers (and for C++ programmers, too) as like salt in your food. You need to use them just enough. C++ aside from pointers also can be salt in and of itself. Like salt in your food it's very hard to pull it back out when you have too much.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Gerry mentioned C# having references instead of pointers. In C++, I have to think about references more carefully than pointers! Not when passing arguments by reference, but when local variables are involved. I use auto extensively, and thoughtlessly writing auto local = rhs copies an object when auto& would be appropriate.
I also have code like this:
void f(Class& arg)
{
if(&arg == nullptr) throw grenade;
...
}So I get helpful compiler hints saying that &arg can't be nullptr in well-formed C++. True, but it certainly can in buggy C++!
|
|
|
|
|
Whut?
Even in simple C# stuff, you use pointers.
honey the codewitch wrote: So especially for those of you that haven't used them much
Those without a real education in the field. Please, gimme more VB6 code to maintain.
If you mystified, then this not a job for you.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
First of all, C#, unless you use unsafe mode, does not give you direct access to pointer ops. I wouldn't qualify unsafe mode as simple C# stuff, particularly since you need full trust to run it. The fact that C# uses pointers under the covers is irrelevant. Every language does.
Second, everyone has to get educated at some point. There's no good reason that education wouldn't include a trip to Code Project.
Third, most of the people I worked with in bizdev knew little to nothing about pointers, particularly the front in web devs, and yet people are still willing to pay them.
Finally, not everyone does this for a job.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: First of all, C#, unless you use unsafe mode, does not give you direct access to pointer ops.
That's a machine level pointer. In C#, safe mode, a string is a pointer. We call them references there to not scare the kids.
honey the codewitch wrote: I wouldn't qualify unsafe mode as simple C# stuff, particularly since you need full trust to run it. The fact that C# uses pointers under the covers is irrelevant. Every language does.
It's not; that's why they explain references and how they "stack" in every beginners course.
honey the codewitch wrote: Second, everyone has to get educated at some point.
I know. I been a surgeon for two years now, and someday I need to learn what a liver is. Not like it's important straight away. I'll google it or ask on the forum if I get stuck.
honey the codewitch wrote: Turd, most of the people I worked with in bizdev knew little to nothing about pointers,
Similar with the Access power user; or any VB user.
honey the codewitch wrote: Finally, not everyone does this for a job.
I'm the one that entertains those questions on the forum. I'm the idiot that reminds people that homework is sometimes a legit ground to ask questions.
I'm here, to help others, for free. Not to tell them that it is homework. CodeProject is more about solving problems that non-coders have these days. I cannot help those, that would make me an unpaid non-employee 
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Well for the record, what is inspiring me to write the article is that I'm getting a friend of mine involved in IoT development, and he knows just enough C++ to be dangerous. It's not his day job.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: he knows just enough C++ to be dangerous. It's not his day job.
"Not yet". And no need for an official education.
We'd have more surgeons if we treated them the same.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It's a good thing you work mostly at night, because I think your friend is about to become your day job. 
|
|
|
|
|
Well, he has a day job too, but he does some programming so I'm not starting from scratch.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Said well.
Here is a C sample using pointers.
Using my rule of keeping pointers from being too saltly, I keep them at a somewhat controlled level
(this is mostly pseudo code so don't cry foul if you see syntax boo-boos
and/or use it and it crashes).
The point is pointers can be very powerful, but must be used with care and with restraint.
/* entry points for routines that do something */
extern int sub1();
extern int xyz();
extern int abc();
extern int subx();
/* put their addresses into a table */
...
struct { int (*action)() } cmd[] = {
sub1,
xyz,
abc,
subx
};
...
int execute_command( char *arguments )
{
int (*go)();
int err;
/* determine index i into the address table using whatever parsing is need to
identify the command intended by the user or the system
*/
go = (int (*)()cmd[i];
/* execute the routine selected by index i */
err = (*go)( arguments );
/* returns error code */
return( err );
}
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
This is just one way of many ways to slice the watermelon.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I'm probably not going to get into jump tables in my article, but you'll be able to create them by building on the techniques I present.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I am not C++ expert, but as I understand it, C is a subset of C++, ergo, anything you can do in C, one can do in C++. This might not be 100% true, but pointers for sure.
"A little time, a little trouble, your better day"
Badfinger
modified 18-Jun-22 19:37pm.
|
|
|
|
|
jmaida wrote: I am not C++ export
I'm as much export as you.
How is it relevant that you are an export?
Assuming you know perpendicular lines, explain .NET without the term "reference".
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
fixed
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
You're fixed? How is that gonna help?
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
