> I'd already understood pointers.
Ok I hear this all the time. Are pointers really that hard for so many people to understand? I'm not trying to brag it took me I think like 15 minutes to grok them from learning about them the first time. I'm sure it took me longer to be proficient but I don't get this legendary difficulty aura that seems to surround their existance.
Also yes nice project.
Job app complete projected archived and abandoned in 3...2..1... :). I hope not.
The issue with pointers is that CS gets taught in a VERY bad way. The way it should be taught is starting with basic assembly on a microprocessor. This trains your brain to think of memory locations and data in memory.
Then when you start using pointers, it makes sense. If variable is a pointer, that means its a memory location. *variable is a way to get that data. Then arrays is just a wrapper around pointer arithmetic.
Whereas with CS, you learn about variables first, which is an abstraction on top of memory, and pointers don't make sense in this regard.
This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals
> This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals
This is largely not the case in my experience. They probably understand the lower level details of manipulating memory better, but there's a lot more to developing software than understanding that memory is a specific place.
>but there's a lot more to developing software than understanding that memory is a specific place.
Yep, and all of that is derivative from how to organize memory. Classes are just more fancy structs. Object creation is memory initialization. Processing flow and code reuse is recognizing memory access patterns. ETC and so on.
All of software engineering is not derivative of memory organization. Algorithm efficiency for example is entirely independent of physical memory implementations. Just because an algorithm may use a set or an array does not make it derivative.
> Algorithm efficiency for example is entirely independent of physical memory implementations
This is wrong. Lots of algorithms behave completely differently based on memory layout. There is typically an inflection point where big O effects start coming into play, but at most scales, memory locality tends to be way more important in determining how efficiently something runs.
Springer press has a book "Programming for Engineers and Scientists" or something like that, which is the first book I picked up to "self teach CS". From the get go pointers are involved and explained in this linear memory model and explained how they work on the stack and what not. I always thought this was the best approach; the reality is taught first, the abstraction (syntax) second. Not sure why so many programming books do it the other way.
> The issue with pointers is that CS gets taught in a VERY bad way. The way it should be taught is starting with basic assembly on a microprocessor. This trains your brain to think of memory locations and data in memory.
Can't agree with this enough. The moment i finally understood what pointers are was when I landed embedded job and during debugging session I looked at memory browser that showed my variable at exact address in memory. After that all about pointer arithmetic and even function pointers became clear as day. Something at least 3 teachers weren't able to explain clear enough.
You can do the same with regular, non-embedded programs in a debugging session
The book "Understanding and Using C Pointers: Core Techniques for Memory Management" by Richard M Reese, is a great way to learn pointers
> This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals
Hah, like fuck they are. The worst code I regularly have to review is written by EE grads. They have less of an understanding of pointers than the people in the office with a CS background.
I have probably like 2000 interviews under my belt across multiple companies. Your experience is an outlier. EE/ECE grads generally can write better optimized software - the only downside is that they aren't thinking as much of maintainability in design of interfaces, but thats a problem that is solved with LLMS
It's a rabbithole. Pointer to array of structures that have pointer fields. Array of pointers to structures etc. You pass them around and trip over the passing semantics, uninitialised pointers etc etc.
Hmm. Perhaps I've just never encountered a hairy enough situation with them? That's what the eternal thought tracker notepad on my desk is for though. Maybe people are trying to do it all in their head? Pen and paper are too old school for the cool new 1000x devs?
I still feel like this argument could be transferred to nearly any concept in CS though. Abstract enough anywhere and you will always start exceeding the brains working memory.
A simple properly implemented doubly linked list or circular buffer is already above the level of most beginner C programmers. Though they're great exercises.
I don't think I would be comfortable saying I understand something if I'm not able to get it 100% clearly just from my thoughts and re-explain it to someone
Everything is just numbers, then we pretend they are arrays, pointers, objects, classes, floats, websites, applications, certificates etc.. The imaginary array can really only contain numbers but we can pretend the numbers are other things, unicorns, rainbows, laser unicorns etc
We are just pretending, there is nothing to understand?
To take this a step further.
They aren't even numbers. They're voltage-high and voltage-low signals.
Numbers don't even exist! You'll never find a 2 in nature. You'll find two things, but you'll never find the 2 itself.
And all 2s are the same 2. But every voltage signal representing a 2 is a completely different voltage signal. Sometimes they aren't even voltage signals! Sometimes they're magnetic flux signals! Sometimes they're electrical field signals! Sometimes they're photons modulated down a wire made of glass!
But the 2 they represent? Not even that is 2. It's 10!
Right, I couldn't find the words. Numbers are also imaginary technology but if you treat high as on and on as 1 and low as off and off as 0 it's so close to reality that it will be hard to find exceptions in software.
Like we pretend it is high for convenience while we really mean higher. For all practical purposes our imaginary world works! hurray!
I can accept that everything else is fake, but UNICORNS ARE REAL, dammit!
That's what most people do. Draw diagrams. Some things like pointer arithmetic which are language features and not just arrows to things and indirection are easy to get wrong though
> Are pointers really that hard for so many people to understand?
Apparently they are; I believe it's the indirection that gets people.
Most learners aren't really taught basics properly - they learn that a variable "contains" a value, when instead they should learn that all values have a type, and some variables hold values.
> I'm not trying to brag it took me I think like 15 minutes to grok them from learning about them the first time.
I can't remember not knowing pointers, so I can't really tell you how long it took for it to click, but I do know that I had done a non-trivial amount of assembly before I used C, so maybe that helped/.
I think it would help a lot if pointers were taught to people from the perspective of how they actually occupy memory, and what the value it stores in memory represents, and then how that value is an address that is followed when a pointer is "dereferenced", etc.
It seems a lot of people assume that pointers don't actually consume any memory and then get confused trying to understand it that way.
Strong agreement.
I came at C after doing 6502 and 8086 assembler. Pointers just made sense because working with indirect addressing and understanding how things were stored in memory already made sense.
The way a lot of teachers teach it is plain trash. I was raking terrible grades in OCaml and C before a student showed me what I needed to know in 15 minutes, and then I would kill it in the remaining exams. Same thing happened to my 68000 course. It didn't happen with every teacher but still, some people really need to get some better pedagogy.
The running joke is that we assume that if you know something you can teach it which goes against everything academia believes in.
> The running joke is that we assume that if you know something you can teach it which goes against everything academia believes in.
What does academia believe, then? I don't know what the negation of "If you know something you can teach it" is.
That if you don't know something, then you can't teach it?
That if you know something you can't teach it?
That if you don't know something you can teach it?
I assume the pun is that education is a discipline like any other. Asking questions, gathering evidence, testing hypotheses, publishing, lecturing etc. Not to discredit people who are naturally fantastic at figuring things out along the way. It just isn't the systemic approach academia believes in.
!(a => b) == (!b => !a), thus "If you can't teach it, you don't know something.". :-)
It's obviously "If you don't know something, you can't teach it."
Pointers make perfect sense.
Now dependency injection, that's some magical bullshit right there.
If you have a class whose constructor depends on an instance of something else, you can instantiate that first and pass it on.
That's all there's to it.
You can do DI in your own startup code and have some logic in there that substitutes mocks when running under test. Or you could change the logging when debug is enabled. Hardly rocket science. If you can write code, you can write the startup code.
If your team likes patterns, dont mention dependency injection unless you're confident it wont get replaced with the framework of the day.
See https://www.jamesshore.com/v2/blog/2023/the-problem-with-dep...
Frameworks turn your DI code into highly complicated configuration. The end result is a giant lump of code whose only achievement is hiding the new operator and possibly also someones job security.
The worst thing with C pointers was for me that the asterisk is inexplicably used both to declare a pointer and a COMPLETELY different operation of dereferencing a pointer.
I still don't understand this decision. I think it should've been like int^ p = &i; ... or ... int i = *p;
Everything clicked ironically when I went even deeper and studied assembly language. Then following pointers to data vs just reading pointers becomes very clear and explicit.
> I still don't understand this decision.
Variable declaration `T v;` means "declare `v` such that expression `v` has type `T`". Variable declaration `T *p` means declare `p` such that the expression `*p` has type `T`". etc.
Nice explanation!
> asterisk is inexplicably used both to declare a pointer and a COMPLETELY different operation of dereferencing a pointer.
This is the most confusing concept of pointers. I feel this could have been easily avoided with different character like ~ or ^ or other.
Why? In C all the declarations work like that:
foo is something, that can be called with an 'int *', which results in a pointer to something that can be called with an 'int', which results in something which can be dereferenced, which is a float.Understanding the concept is easy.
The problem arises when you start to mix memory management with more complex structures.
It’s extremely easy to make mistakes, and you must be very careful about ownership and clean up. Those things are not strictly related to pointers, but in C, it’s inevitable to use pointers to handle them. That's why people say pointers are hard.
Yeah, it's one thing to understand "a pointer is a location in memory". It's a completely different things to understand what to do with that information.
When I first started learning to program, it was in C, with one of those "Sam's Learn Yerself a C++ in Eleventy-Three Days" books. I was, like, 15 or something. This was long enough ago and my family was just barely poor enough that we didn't even have the Internet yet.
The book explained memory. That was not hard to understand. But we had been using stack-allocated variables through several chapters in the book so far. I didn't get why you would ever want anything as a pointer. If I wanted to write a program to add 3 and 5, why wouldn't I just say "int x = 3;"? Why bother with this stupid dereferencing syntax? Given that the author chose to explain pointers by first explain the address-of operator on stack allocated variables, it felt particularly perverse. The regular, ol' variables were right there! Why but just use them
I didn't have a concept yet of what one could even do with programming. Hell, just a few years prior to that point, I was pretty sure all of the other programs on my computer were written by massive teams of wizards manually typing out 1s and 0s.
I still managed to bungle on and write code. But my programs in C never really worked well. Though, they still worked better than my classmates' versions! Then, in my 2nd year of college, I had transferred universities and the new place taught in a Java.
Java was disgusting. It was so verbose. Why did we need all these weird, multi-sylabic, period-infested function calls to do anything? Why was it so slow? Why couldn't I write ASCII-art graphics with it? Why couldn't I run my programs on my friend's computer?
It wasn't until I had taken computer architecture that I gained a much better understanding of what any of all these computer things were meant to do. I ended up implementing a basic scripting language in Java. And then, suddenly, I understood pointers.
> Are pointers really that hard for so many people to understand?
Yes, anyone who has taken algorithms and data structures class in C knows that some people just don't get it.
Also the way people teach it tends to be bad, before teaching pointers you need to teach Stack and Heap at a conceptual level.
"Are pointers really that hard for so many people to understand?"
The * vs & always gets me and not to mention if I ever have to deal with Pointer Math.
Think of it as types. All of the following are the same thing (declare p as an int* type). It's important for the end :
Now remember that the type is a memory address. I'm sure it is semantically wrong for whatever reason somebody will explain but it helps to think about it. So you can do : Both sides of the "=" are the same type (int* is an address, and &my_number is also an address, the one of my_number).Now p is a pointer (or an int* or an address), and *p is... an int ! So this is totally valid :
and for anything else than int you need to malloc that so you will see a lot of : which makes sense because malloc returns an address (the beginning address of the content of s ; yet again somebody will tell me I'm wrong to call it "the content of s" so sorry for that).> int* p
I don't like that syntax, because it confuses people. It might be sensible to think of the type as (int *), but C just doesn't work this way. You might never declare more that a single variable in a statement, but it still gives people the wrong intuition.
> int* p
I very much prefer that syntax, because the '*' is part of the type, not part of the variable name.
> You might never declare more that a single variable in a statement
Yes, you can do that, and in fact if you want to declare multiple pointers on the same line, you are required to put a '*' in front of every pointer variable name.Personally, I've always considered this to be a defect of the language. Would it really be so awful to have to write instead:
But of course that's not the language we have.I'd be very curious to know the motivation for requiring a '*' in front of each pointer variable name, as opposed to once with the type. So far the only ones I've thought of (not mutually exclusive) are:
a) we REALLY love terseness, and
b) ooh look at this clever hack I came up with for variable declaration syntax.
> because the '*' is part of the type
I agree with you that this is an obvious mental model and it might be true for other languages, but this isn't the model that the C language has, which reveals in the fact that:
does not declare two pointers.You can see it like this: C does not have a way to declare a variable to be a pointer to int. In C you can only declare an expression with a variable to have the type int.
That's why I don't like this syntax especially for beginners. It is deceiving. It leads to people thinking it works differently than it really does and coming up with weird mental models. For example, that the unary '*'-operator has two meanings: dereference and declaring a pointer. Than they say a pointer should better be denoted by '&', because that's the address-of operator. But that's wrong, unary '*' always means dereference. You don't declare 'a' to have type 'int *', you declare '*a' to have the type 'int'!
It's the same with array syntax (and also with function pointers and really every declaration):
I agree that it doesn't cause problems for people who are experienced in the declaration rules of C, and it might never cause confusion if you never declare multiple variables in a line (I never do, because of diffability), but when teaching it leads to the wrong user model. Show 'int* a, b;' and people are confused, show 'int *a, b;' and it is obvious how it works.Someone said in another comment, that it makes more sense together with the dereference operator, so int *var means: "dereferencing var gets you an int."
I don't really know C, but personally prefer your version. However, I can also get behind considering the * to be part of the variable, rather than a type: "var is a pointer that happens to hold an int". I mean, maybe they could have used the & operator meaning "var is an address holding an int"? Honestly, it just feels like there's too much tradition and legacy and so on, and what one considers intuitive is the thing that they're most used to.
*pointer = what pointer points to &thing = address of thing
Pointers in and of themselves are not difficult to learn on their own, but when you're learning them alongside your first programming language, it's just adds to the difficulty I think.
I think a lot of noobs learning C struggle with pointers especially because there are no good error messages besides "segmentation fault" :D
The concept is straightforward. The syntax isn't. That's why cdecl.org exists.
C gibberish to English gave me a chuckle thanks.
I learned assembly language long before I learned C, so pointers took me about 2 seconds to understand. I suppose it may depend on previous experience.
> Are pointers really that hard for so many people to understand?
Yes. Especially pointer to pointer to ...
The big problem is that arrays are conflated with pointers because C doesn't do slices. If C had slices, people would naturally avoid pointers except in the cases where they were genuinely necessary. That would make teaching pointers vastly easier.
I understood them on a superficial level when first learning about them, but it only really clicked after having done assembly.
As a 16 year old who learned programming by hacking together bad ActionScript3 flash games, it took me way longer than 15 minutes. Once I got it I got it and there was no mystery from then on. But there definitely was a hurdle.
The legendary status is also enhanced by the absolute nightmare that pointers enable if used with indiscretion or high level proficiency - a triple pointer is a good example for me but there's many many more, and arguably worse, examples out there.
My favorite is pointers to functions passed as args for things like supplying a comparator. With more opaque void* args for customizing things even further.
Same here about pointers. Perhaps it's cause I started life as an electronic engineer and understood memory addressing from the chip level but I, too, don't understand the struggle others seem to have.
I started in networking so there were a lot of memory/bit-logic/binary concepts piled on early maybe that is the case.