4 ms·
I never really understood why they didn't grasp pointers The root of the problem is the language designers' loose use of star. "star something" is contained in
by cturner 15y ago
I never really understood why they didn't grasp pointers
The root of the problem is the language designers' loose use of star. "star something" is contained in a phrase that means one thing at declaration, "star something" has a different meaning the rest of the time.
#include <stdio.h>
void eg(int i) {
int *j = &i; // "huh? Put the address of i into *j?"
*j = *j + 1;
printf("%d\n", *j);
}
int main() {
eg(4);
}
With more detail. In the line..
int *var = something;
.. the system assigns to the pointer. Yet in..
*var = 6;
.. it assigns to the contents of the pointer.
Common usage creates further room for confusion:
int *var; // <- this is what people write
int* var; // <- instead of this
If they'd made the syntax ".int var", and then used * solely for dereferencing, people wouldn't have these problems learning pointers. Consider
#include <stdio.h>
void eg(int i) {
.int j = &i;
*j = *j + 1;
printf("%d\n", *j);
}
int main() {
eg(4);
}
Further confusion comes from (1) special arrangements around string declaration and (2) printf use of %s to expect a string pointer when %d and %f expects (non-pointer) simple int and simple float.
char* something = "huh? so now this does goe into *something?";
- endgame 15y agoIf you remember that the experiment here was to make declaration follow use, it makes sense. I consider it a failed experiment, but it does make sense.
- deleted 15y ago[deleted]
- atakan_gurkan 15y agoTo avoid this sort of thing, I use: #include <stdio.h> void eg(int i) { int *j; // "j is a pointer and (hence) *j is an int" j = &i; // "Put the address of i into *j? Yup" *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } Perhaps this is because I am just used to it, but I really see very little room for confusion here. The common usage avoids confusion, if you do not insist on assignment at the time of declaration. To address your second confusion, just keep in mind that strings are char arrays and an array's name is actually a pointer. Again, I find this very straightforward.
- cturner 15y agoI really see very little room for confusion here. I don't understand how you reach that conclusion. You might understand it, I don't see how you can say there is very little room for confusion. Yes, if you know about declaration follows use, it makes sense. Yes, if you "keep in mind that strings are char arrays and an array's name is actually a pointer" then it makes sense. You can get by by knowing to avoid some constructs. If you know how the c compiler works, pointers make sense. If you know C then you know C. But when you're new to the language, you don't know these things and that's what this part of the thread is discussing. Another responder wrote: The key is that * is part of the type of the declaration, not of the variable; an int* is not an int. The grammar is structured as though it's not. Consider this: int* c, d; Since star is part of the type, if the language was designed well then both of them would be int pointers. But in that case, only c is. d is an int. Awful.
- Goladus 15y ago> if the language was designed well Do you mean to reinforce that the language is not beginner-friendly, or are you really asserting that makes the language poorly-designed? If it's the latter, you should really at least explore some other factors before making the conclusion. It seems to me that it's a relatively minor distinction once you know it, so from a design perspective that may simply be a tradeoff for some other advantage.
- cturner 15y agoDo you mean to reinforce that the language is not beginner-friendly, or are you really asserting that makes the language poorly-designed? I was seeking to account to ramidarigaz why his CS classmates didn't understand pointers. I think poor grammar is poor design - i.e. part of the type affects both variables (int), the other part doesn't (star). The other issue is use of star to in one place to mean create reference, in others to mean dereference. That was the focus of my first post. from a design perspective that may simply be a tradeoff for some other advantage. I've yet to see evidence of any. What sort of things were you thinking about?
- roel_v 15y agoThat's because of the (visually) 'wrong' use of * (wrong in the sense that it's unintuitive). The key is that * is part of the type of the declaration, not of the variable; an int* is not an int. So int *j = &i; is more correctly expressed and easier to understand when written like int* j = &i; The only reason to put the * in front of the variable name is when declaring several pointers in one line. So the solution is to only use it that context, or not doing it at all.
- alecbenzer 15y agoThis bothers me so much about C/C++ syntax. int* a, b; should clearly declare two int pointers, not one int pointer and one int. Stroustrup wrote something somewhere where he explained that int* a; is more appropriate for use in C++ because C++ is supposed to be more focused on types, and int * a; is more appropriate for C because of something about C's philosophy, but I can't remember what. I wish they would have changed the syntax for C++, but I guess he couldn't have while still keeping C++ a superset of C. edit: found it: http://www2.research.att.com/~bs/bs_faq2.html#whitespace http://www2.research.att.com/~bs/bs_faq2.html#whitespace "A ``typical C programmer'' writes ``int p;'' and explains it ``p is what is the int'' emphasizing syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the style. Indeed, the * binds to the name p in the grammar. A ``typical C++ programmer'' writes ``int* p;'' and explains it ``p is a pointer to an int'' emphasizing type. Indeed the type of p is int*. I clearly prefer that emphasis and see it as important for using the more advanced parts of C++ well."
- deleted 15y ago[deleted]