That analogy between memory address and the address of a house is great! I used to make similar comparisons when teaching C to students and it really seemed to help make it click for them.
Dave, i have been coding in C since 1980 and have, many times, tried with variable success to explain pointers to newbies. This video is clearer and more concise then my best efforts. Going forward I'm just going to refer newbies to this. Thanks.
These three sentences solved the big problem I was having when learning pointers: "Depending on the size and complexity of the house structure that could be an expensive and wasteful operation. Why is it wasteful? Well because just like in real life there's no reason to bring your house to the appraiser for an appraisal the appraiser comes to you." I was always so confused as to why you would use pointers when you could just carry the whole object around. But because it copies the entire house variable, which is often more data than a 8 byte pointer, this makes it efficient to use on any item that is larger than the size of a pointer. Thanks a ton!
Also, if the function you passed the House to modifies any member variable of the House, the original House that you had will not be the one that gets modified -- instead, the copy (which will be thrown away when the function is finished) is the one that gets the changes, which is probably not what you desire to happen. Using a pointer allows the original House to be modified, which is probably the expected behavior.
One of the best exercises I ever did was learning to setup a 2D array in one malloc, so that it can be accessed by array[row][column]. I don't think I really understood pointers until I did this. If that's easy for you, do a 3D array. If that's easy, you are good at pointers.
Its a great video if you understand pointers but it fails to do the most important part of why people don't understand pointers. People don't understand pointers because they don't understand the problem they are solving. The moment you understand how memory works, how data is stored/loaded in/from memory and what the cpu has to do differently depending on if you call by reference or by value is the moment you get pointers. The real explanation needed is not what pointers are but what problem they solve and why you need them. Back when i was learning C i had a hard time wrapping my head around pointers until one day my boss took an houre to explain the difference. He showed me the assembler output of different scenarios with and without pointers and explained what happened on each line inside the cpu and memory and it just all made sense after that. It's not about what pointers are but what problem they solve and how.
Yeah assembly could have explained it simply.. You have Registers, and direct/indirect addressing… all registers can be pointers unless they all are general purpose registers Then the addressing and instructions decide how we are representing the registers LA R1,=A(0000) Load address of location where =A(0000) has been resolved in the executable, into Register 1 XC 4(256, R1), 4(R1) XOR 256 bytes starting from values pointed by R1 offset by +4 bytes with the same… (XOR of itself is 0 ie clearing all the bits/bytes at that location) ST R1,INT32 Store value in R1 into location INT32 L R3,INT32 Load value at INT32 into R3 LA R4,INT32 Load absolute address of symbol INT32 into R4 ST R3, 0(R4) Store R3 into INT32 symbol location INT32 DS 4F Someone who knows assembly should be able to teach pointers in a better way
Wow, 40 years ago I was still programming Fortran and had never heard of object oriented programming. At the time I was designing a production program to run various tests on pacemakers and since all the tests had some shared behavior (like limits checking, saving results to a database, printing results, etc.), I decided to create a large common block array that was indexed by something I called a "test number" then functions could do what they needed with just a test number. One huge advantage was that I could configure what tests to run and what limits to use and units to report with a big constant array at the top of the code. This meant that when a new test specification came out, usually all I had to do was to change the constant array and no code change was required. Later on in my career my SW boss told me I had created Object Oriented Fortran. Interesting - I was just a young "lazy" programmer trying to find a way to do more with less code to develop, debug, and validate. Also, being ADD, my brain worked faster than my fingers.
@@tangiblewaves3581 well i agree but i dont agree, i think we always find shorter ways to do things and yes we develop wicked tech from it, but programming its self can be very intensive / labor intensive. And takes a lat of work even to learn, so i get what your saying, but programmers are just like any trade (plumbers, electricians) and just like those trades look for better ways. I have a family full of trades, and they are full of unique (what i would call lazy) ways to fix stuff but it works and they have good solid reputations for the work they do, sometimes its those ways that make a completely new product that works 10x what the previous method is, but it takes knowledge and the skill to think it through (and sometimes the balls to apply the fix lol and hope it works.) just like them, programmers, designers and scientist need to sometimes "go back to simple" in order to step forward. All that said... i have seen lazy programmers and lazy plumbers. so i think the ratio is likely the same in terms of avoidance of physical labor. o7
@@NanoGameLab exactly, and if you want to code proffessional, you also need some good amount of discipline to code even when you have a bad day or are tired.
Pointers were so logical and intuitive for me. When I was first learning C++ I was coming from having played around with languages that didn't have dynamic allocation, I didn't know what dynamic allocation was at the time but I had been frustrated in numerous projects I had made that I couldn't make new variables at runtime. So when I first read an example of malloc and using a pointer I immediately put down the book (before even reading the explanation of the example) because I had recognized it as the solution to what I had wanted for so long and wrote a linked list (not that I knew that it was a linked list at the time) to verify that it could do exactly what I had hoped it could, and it worked. I was so excited, the possibilities of pointers were limitless in my eyes and I messed around with them for most of the rest of the day. When I finally got back to reading the book that I was using to learn C++ I was a little disappointed to learn that everything I thought I had created to use pointers for was pretty much covered in the next chapter, but I was glad that at least I had understood them well enough that I could correctly extrapolate their uses without knowing much more than that they existed. It also turned out the example was only the first half of the program that only covered allocation, it wasn't until I turned the page to see the deallocation example and read the explanation for it that I realized all the horrors of memory leaks and how many I must have created that day 😉
@@IBelieveInCode Logo and Visual Basic, though I was very young at the time and no internet so I might just not have been aware if they actually did have that capability.
Honestly i don't have any problems at all understanding the concept of pointers, all that makes sense to me. What i don't understand, is when you want to use them
Maybe that is the right way to tech the concept, is to pose problems that require the indirection to do the job. A lot of things are easy if the person thinks it was their own idea or something they want rather than something imposed from outside. Get them to say for themselves "what I really need is some way to ..."
@@TehIdiotOne as said on this video, the most common use is with larger or variable data types like objects, it is much more efficient to point to the adress of an object than bring the entire object into memory, this is especially noteworthy in C++ when storing lists of large objects or integers, you just use the pointer and the -> operator and it is way more memory efficient. Plus, it allows for dynamic memory allocation which allows to manage what is and what isn't in memory at any given time
This is the most amazingly coherent, clear and informative explanation of pointers I have seen in 14 years since I started programming in C and C++. This is beyond fantastic omg please continue. :)
I've been (slowly) learning C as my starting language just for fun. Pointers has given me many headaches and I still can't completely get a picture in my head of how they work. I wish sometimes that they had a special name or different symbol, maybe that would've made it easier. But you mentioned a few things (that I had to listen to 3-4 times) that gave me some better insight, so maybe one day. Thanks!
C and C++ learning is like this: you learn the basics and start writing. Then you want to do more or understand someone else's code, at that point you go through 3 to 6 months of FOG where you don't quite get it, but you keep trying. The good news is once you get past that, you become a decent programmer.
@@newmonengineering I basically set out to make a reasonably simple game and by using reference code from others or books I've managed to piece things together bit by bit. By interpreting compiler errors I've managed to kind of get a feeling for when it's in need of a pointer or not. So I definitely know more now than half a year ago luckily :)
I think C started a bad pattern for working with pointers because you declare one with the same symbol you use to dereference one. That said the arrow operator has some, as of yet untapped, potential for conveying ownership semantics needed for automated resource management (at the cost of the control C devs freak over :p)
Two follow-up tips: The & (address-of operator) is used when you want to turn the address value of something into a pointer. Second, you will sometimes see that asterisk * in different places between the type and the pointer name: e.g. int* a; int * a; int *a; int (*a); ... all of these are exactly the same. The whitespace doesn't mean anything in these examples. That took me forever to understand. Just try to be consistent in code.
int* should be the only way to write int pointer.. everything else should be banned 😄😄 To me it makes the most sense. The type is an "int pointer" so put it with the type name... I think it's confusing for beginners because it looks similar to the dereferencing syntax.
@@JamieT1986 yes, but then a declaration in 4:07 would create 2 pointers, not one. int * x, y is in actuality: int *x AND int y. I agree it would be better to just have something like 'intP x, int y' and then it would be obvious what is a pointer and what isn't but we got stuck with a syntax that is efficient for writing, but hard for reading - somewhat opposite to Python's syntax.
@@vaakdemandante8772 int* x, y; is something I was a little skeptical about actually when I saw this. I never knew that's how it worked, and I forgot to test it myself. I will assume it's correct... but yeah that kinda screws it up! :)
"int \*num" is much better, the declaration in 4:07 is confusing if you use the "type\* var" version. Edit: I used "\" sign cuz youtube comments converts asterisk to bold letters. lol
This^^^ i would say, find a style and stick to it, but as an OS and firmware dev the most common style i come across (and use personally) is this: Type* var_name = ….whatever here…. Ex: int* pointer_to_integer = (int*)malloc(sizeof(int)); So the asterisk essentially lives right next to the type, with no whitespace between. This makes it clear that it is a POINTER of said type, in my example a pointer to an ‘int’ Using this style consistently makes reading and reasoning about pointers much less frustrating in my opinion. Of course, then there is dereferencing a pointer to get the object’s value. In those cases common style i see and use is this, continuing with my int example: int integer_variable = *pointer_to_integer; So we use the asterisk right against the VARIABLE NAME to dereference it. The combination of sticking to these two basic style guidelines makes points way less messy. Essentially, use the asterisk directly next to your type name when declaring a pointer variable, and right next to the variable name when de-referencing it. Hope this helps some of the less experienced! Also, as a follow up, i think the example at 4:07 of Int* x, y Is a kind of poor example. It just isnt code that would fly in most (well maintained) C projects like the linux kernel for example. You want things to be CLEAR above all else, and so its not really much effort to be explicit with each variable declaration. The compiler can optimize for you if it is necessary or possible. Otherwise, be more verbose in an effort for future contributors to have an easier time grasping what your code is doing. Little syntax tricks like that can be neat, but often fall flat in well maintained project environments with C.
i was a TA for an intro to C class, and the house example was what i used to describe pointers to people really confused about them. glad to see that you are using a similar example here! i feel that the easiest way to describe technical concepts to people who are confused about them(or have no technical experience/knowledge) is to use a real world analogy, even if it oversimplifies what is actually going on. once they understand the analogy and how it relates to the technical concept, then they can get to the nitty gritty of understanding the technical details behind the concept
This is my 4th time learning C and pointers in 32 years, and this is probably the best explanation of pointers I've ever heard. Although maybe thats because this is my 4th time learning pointers. Who knows, great video none the less sir!
I started learning Turbo Pascal in the mid 90s, so for me pointers where never really hard to grasp as TP uses them too. Once you have the concept in your head a pointer to an array of pointers becomes a natural thing to work with. Great video!
I first used pointers in Pascal on a mini computer in the mid 80s, and then Turbo Pascal in 1986, although I was also an assembler programmer before that, where you use pointers all the time but call it indirect addressing. Pascal taught me about structures. Then I went onto C, but it was K&R, and I found the nomenclature hard to follow: it took me months to get proficient, not because I didn't understand the concepts, but because K&R C can be super impenetrable for a C noob. Thankfully ANSI C came along at just the right time, I re-wrote the K&R code I was maintaining in ANSI, and I've stuck with that ever since. C remains my language of choice to this day, but mostly I'm a deeply embedded systems programmer and mixed signal hardware engineer, where C sits well, nice and close to the hardware. I dip into assembler still every now and again for those pinch points, but 99% is C.
On the first example, it is important to note the memory address needs to be casted to a byte pointer. When I was learning, this confused me a bit, especially when working with custom types. You can have an entire buffer filled with data which looks random, but if you cast it to the correct type when dereferencing, all values in the custom structure are magically decoded, and it is extremely fast!
Because i guess you did not start with assembly langauge. This was my 2nd language after Basic .... like all teenagers in the early 1980s home computer time. Feeling sad for the current generation that think it's not only magic but black magic.
@@llothar68 actually, in my Electrical Engineering curriculum in 1999 I took a class in ANSI C in Unix and an Assembly class. In the Assembly class I wrote a 8088 CPU emulator, which was both frustrating and fun! I ended up using assembly programming PIC microcontrollers more than anything else. I used the term “magic” because I know what it is doing under the hood for me, and how much effort the C language saves us rather than writing in pure assembly! Cheers! Edit: it was the 8080, not the 8088-long time ago and I have lost the floppy disk where I had a backup. Oh well…. My degree is in Electrical and Computer Engineering (ECE) and I took quite a bit of digital design classes, focusing more on hardware than software.
@@llothar68 im self taugh software engineer, i did not went to cs, and I know this stuff, cause I love digging deep, no need to feel sorry. most of these jobs doesnt require this knowledge, yo ucan still learn it as hobby
30 years ago I learned about pointers in C, and I’m grateful for this recap. Some things made more sense even now, after watching this, particularly the double indirection.
Pointers, and pointers to functions, are a powerful tool. My C programming days are over (now Python), but using these tools with data structures (linked lists, queues, trees) is indispensable. Great topic, and well taught. 😎👍
5:41 The -> pointer "dereference operator" is the shorthand variant for (*struct_name).member e.g. (*pHouse).SquareFeet 11:00 Usually when we program in C without classes ,we are using malloc. In C with classes (C++) we use new. Syntactically are both correct but new is safer. 2:58 Hardware registers or memory locations (physical memory locations on a CPU without MPU/MMU) can be accessed using a single line of code like *(byte *)53281 = 0x00;
"Usually when we program in C without classes ,we are using malloc" It depends on the platform and application: in embedded microcontroller applications, which are typically memory constrained. would fail catastrophically in the event of failure, so malloc is rarely used in production hardware. As a result, memory and objects are typically allocated statically, or on the stack (typically small objects only on the stack).
@@danielrhouckNot really. Stroustrup referred to C++ as "C with classes". If it's good enough for him, it's good enough for me. It's a nice succinct way to describe the language conceptually.
Good video, Dave. I also have been working in C/C++ for about 40 years, including work for some notable compiler vendors such as C86, Zortech C++, and GCC (via Cygnus). This was IMO an uncommonly clear and well-organized presentation. Was impressed that you had time to include pointer-to-functions in this 14-minute overview. Perhaps you might have mentioned the precise prototype matching required to do real-world useful work involving pointer-to-functions; and in particular, how judicious use usually warrants declaring a typedef for a particular group of related pointers-to-functions.
Dear Dave, you said something really wonderful. When you want to learn C++ or C but your first language is Python, of course, it looks scary. That is what I can hear from a lot of students who are honestly scared to delve into low-level languages and learn how "motor" actually works. Since I am a child of the 80s, my first language was machine code and assembler for 8-bit CPUs. As such, I always try to explain things from that perspective, emphasizing memory and how the CPU "crawls" through it. Thank you for this episode. I truly believe it is important. Greetings from the Netherlands.
As a veteran assembler and C programmer of over 45 years, I can tell you that Python is scary to me. I seem to spend more time maintaining a working development environment than I do writing code in Python.
@@nezbrun872 That sounds kind of disgusting. I've never dived into Python. I started with C64 BASIC and jumped to machine code after that. A few years later when I got into college I got introduced to Pascal. After that I pretty much went into C, because I was fascinated with MUDs and wanted to learn how to run one and modify it.
I was once in a class where students first learned Visual Basic and then moved on to Java. And I can say that Dijkstra was right, learning this way actually harms students.
@@nezbrun872 Dear, I totally agree with you. You have less control on data flow. Young people who are using languages as Python, then just don't think about memory, about what is going on behind.They rely on some, what they call - libraries, but it is more like the whole Lego block, framework. For me library is part of the OS or what I build for myself (: I'm glad there are more people who feel the same. Thank you for sharing!
6 years of college working in C++ and i had never even heard about function pointers, thanks for showing me something i didn't even think was possible!
Function pointers are kindof the origin of object oriented programming. You would create a struct with function pointers as member variables. Then a "constructor-like" function could initialize the struct with the desired functions and voilá you have a class. C++ started out as a transpiler to C and, I might be wrong on this part, that is how i think it translated c++ classes into c structs.
Function pointers are currently almost not used (directly) in modern c++ (of course they exist and can be used if needed): most of the functionality was moved into lamba/function objects which is more robust and powerful solution (with some small problems). Also operators new/delete should not be directly used (as smart pointers are better option with make_shared and make_unique templates).
Holy mackrel I don't think I ever rewatched a single video consequtivelt as this. Sir, in 12 minutes, you explained pointers better than my professor in an hour and a half.
Thanks for making this video! I still remember the exact ‘ahah’ moment (two decades ago in freshman cs) when I grokked c memory (pointers, arrays, structures). Learning how c handles memory really helped me understand how computers work.
Thanks Dave for revising my C concept. Last time when I did was solving exercise of K&R in 1 st year of graduation. Clap for your line "I am not here to sell anything".
Been doing C/C++ for 30+ years. Think I started C when I was around 15 or so. Pointers were fairly easy in terms of grasping the concept. I had to figure out pointers to pointers on my own as I was writing a DOS tilemap level editor for a game I was working on. I wanted the menus to be dynamic and each menu item (string) varied in length and the menus could have a variable number of items, so pointers to pointers it was. It doesn't really get messy until you're doing weird multiple level casting and de-referencing. That usually trips me up if anything.
You can also subtract a end pointer from a start pointer to get the length of data or string. As for void pointer if you use the same format for all your structs then a uin64_t in the beginning can be used to identify the data type.
Working in assembly will really make you appreciate pointers. The scary part of C and C++ are all the special characters, it just looks like you could hurt yourself, which, you can. C teaches you to have good habits, if you are using it for production code where YOU get the call at 3:00 AM if it crashes.
Coming from IBM assembly with it's base address + offset instruction format, C/C++ pointers were a piece of cake. Anyone remember the USING or CSECT directives? Fun times.
My experience with pointers came with my first programming being PDP-11 assembly (school) and later 6502. So dealing with them in 'C was very straightforward...after the syntax of course. I say that because your comment about 'decorating the variable' rather than the type, (int* x is not int *x) was my personal stumbling block.
My first language was BASIC (GW-BASIC and QBASIC) and Visual Basic. I had heard about how scary pointers were, so when I learned C in grade 11, I made sure to pay close attention to the lesson on pointers. And... they didn't seem so scary. Suddenly a bunch of things about C (and even BASIC, to some extent) made sense. Later, I would sometimes get confused when working with double and triple indirection, but generally pointers never seemed too difficult. I think it was that moment that I realized I was meant to be a software developer 😆
Good for you. I think pointer fear is the result of insulation from it in some modern language contexts. Anyone used to assembly / low level C coding would have no such fear because it's absolutely certain that they would have to have dealt with it from day one.
The Aha! moment here is pretty fun. Pointers aren't necessarily as confusing as their use cases are not very intuitive for a new student. The house address analogy does wonders for assignment and copy constructors, though! In C++, making a copy of a house to show someone what it might look like is an incredibly vivid idea for me.
The very first programming language I learned, back in 1995 when I was 11 years old, was C. I had to tackle pointers from the get go, and of course they were a difficult topic for a child to grasp initially. But it made a HUGE difference for me when, years later, I started learning more high level languages such as Java, C#, and Ruby. I was WAY ahead of my colleagues who were learning those as their first programming languages, as the internals of what we were doing were much more intuitive for me.
Dave, I've been watching your channel for a while now, you might not read this, but I found this video very interesting. I started to learn to code several years ago, and got stuck in tutorial hell in several language. C is the first one after many years I've actually stuck with. I guess my brain is wired different, so the features of a lot of the new languages have too much abstraction for me. I like to know how things actually work, and C has been a huge stepping stone for me to finally get into software engineering. It's been more of a hobby for me, but I would like to do something involved in it whenever I retire from the military God willing. I understand hardware very well from my background of troubleshooting, and working on weapon systems that employed digital electronics, radar theory, signal data conversion etc, but programming was always a mystery for me, it sounds stupid I guess, if I can grasp hardware, software should be easy. Thankfully C exists. My question to someone with your background, is there a good method of connecting with people other than reddit, that could help with pointing to resources to expand my knowledge on C and the data structures/algorithms that are needed to be learned in the industry?
Thanks! Very Helpful. You explained some things that C++ books that I have read have overlooked. Like ..... The reason why we even need to use pointers to begin with. I hope to see more content like this.
I learnt about pointers in high school. Having programmed in a higher level language for the next decade or so I really never needed them except for knowing they’re really what's used under the hood for all the syntactic sugar I grew accustomed to. What clicked for me was when, trained to use polymorphism I tried to obtain the same result in c++ embedded only to realize you cannot send daya structes of different sizes to same function. Using pointers was the solution for passing different implementations of an interface of varying byte sizes.
The 53281 example made me nostalgic. I've only recently started coding in C, but so far pointers have seemed pretty logical to me, maybe because I grew up on constantly referencing specific addresses in memory on the C64.
Hi Dave, I discovered your channel a few days ago and enjoyed some windows related vids; today I wanted to improve my understanding of C pointers and, voila, here you are again! I looked at some other tutorials, but yours is definitely the best! I really love your style! Keep up your great work; it's pure gold! ❤
I recall a textbook that described the pointer, and then said, "At this point, the point of a pointer seems quite pointless." They aren't, but the line was good.
I once had to create an array of function pointers. I remember nearly going blind with the syntactic gynastics that was required to create the thing and actually use it without leading to memory leaks. That was some 30 years ago, when I was programming embedded systems. Anyways, I strongly agree that mastering pointer syntax is important to improve your code READING skill. Oh, yah, and I heavily commented all that code. I typcially had more comments in my code then code, but I recall going way overboard commenting that code.
Function pointers are very useful in things like emulation. Setting up an array of instruction codes, with the value being a pointer to a function is much more elegant than a massive switch block (plus you can easily add placeholder functions that haven't been implemented) 😁 It's also handy to cast pointers to different types for performance. For example if moving a large array of 8 bit ints (e.g. RGBA data from a buffer) to another location (like display memory), you can cast to a 32bit or 64bit int pointer instead and move blocks of 4 or 8 at a time, and only drop down to 8 bit for the last few.
They are also the basis of how member functions really work in C++. It is possible to create your own system of "Virtual Method Tables" in the C language to get very C++ like operation in a place where it is needed. Your array of pointers to functions that carry out operations is a type of VMT. You could make a different micro being emulated by making a new variable with a pointer to a different VMT as part of its structure. Thus you can make the version of the micro controller with no multiply and the one that does a multiply and switch in the right one.
@@kensmith5694 Ever since I started programming C in C++ I've realized how terrible virtual classes are. Creating a struct with function pointers is infinitely more flexible than the limited tools C++ gives you and it's so much easier to understand.
@@smushy64 Virtual member functions can be a good tool but sadly it is a round hole that many try to fit a square peg into. The design of C++ kept some mistakes from C and then added some new ones. The C++ library also contains some fairly obvious mistakes that now programmers must live with.
Excellent! I am coming to C++ and Rust from other linguages both compiled/assembled (primary) or interperted. (50+ years in programming -- livelyhood/ hobby to retired and just hobby). If this is a topic that should be explained: o Coding: Best Practices, with emphasis on: - Readability via Logical Format (after or along with the comments to explain) - Preventing Memory Leaks > Tools Available To Check - if such a thing exists Links to, if this is something best explained by examining what you consider good coding practices. Programming helps keep my mind sharp. Plus I just love it. When working I got paid for what I would have done for free (well almost). Looked up and it was time to go home. Couldn't wait to get back to where I left off. Thanks again,
We use pointers for everything at work. I mean EVERYTHING. Network structs? Passed around everywhere as pointers. Passing around random data structures that you don't define until runtime? Void pointers. Needing to access a player and all their information if building video games? Pass around const refs to the player
Online course sellers hatehim! Man shows up, explains the important things and crashes a whole 15$ course industry!!!! Actually I never understood half the things you talked about because I was reading about them on stackO or those CS50 notes. Thanks a lot!
Thanks for your programming content! I have been a programmer for a while but nowadays information technology seems much too complex for me. I cannot code for real but I can follow your explanations and understand them. It's just I have problems memorizing them. So I consider your videos a source of sophisticated entertainment.
I don't think I ever had an issue with what a pointer _is_; however, the syntax around the implementation is where I still get confused from time to time. (It does not help that I've only ever used C/C++ on an as-need basis.) IMHO, the most difficult concept to understand is using the star operator to declare a pointer but also to deference said pointer later. The second is the arrow operator - more to the point, when to use the arrow operator vs. the dot operator when dealing with structures. This latter issue becomes even more fun when you have pointers to structures which include arrays or other structures, where you now have the arrow operator and dot operators both to ultimately access some member of the structure. Your video really helped me here - I never realized that very important distinction, and I really appreciate your explanation. Love your videos - keep them coming :)
When it comes to understanding the reasoning behind the way pointers are declared in C, the best explanation I've heard is that you read from the variable name to the right and then to the left, so int foo; // foo is an int int *bar; // bar, when dereferenced, is an int int (*fn_ptr)(int, int); // fn_ptr, when dereferenced, and when called as a function with two int parameters, is an int. Alternatively: fn_ptr is a pointer to a function that takes two int parameters and returns an int
Thanks, Dave! This is what I'm talking about! Coverage of more advanced C/Cpp topics. Please keep up with explaining some applications where the topic-of-the-day is used. I will say again, your knowledge should be memorized in a book. I would buy two!
The general concept of pointers has made sense to me for a while, but I've struggled to follow examples that use them or design my own programs. I think your video explored them from an angle that finally made a few things click for me, learning to use them effectively will still be a task but I think I can see some of the patterns now lol
Had this discussion over and over and over again with people saying the C/C++ is dead because of pointers. I'd love to work on a project again where C++ is used in the back and front-end. It is the most robust way to program anything. Anyone that doesn't know how to program in C or C++ and how to work with pointers is a "Kiddie scripter" 🙂
Get into resource-constrained embedded systems where we still care deeply about memory utilization, raw performance and power consumption. Almost all of it's still in C, and written bare metal.
@@DavesGarage Yup. Already watched it. And yes, I've used auto_ptrs and then later the shared_ptrs from boost. This is, of course, now part of the standard library. unique_ptrs replaced auto_ptrs. shared_ptrs are quite convenient for resource sharing across multiple objects and threads
Starting on the commodore 64 where everything was done with poke greatly aided the lion kingdom's introduction to C. Of course, younger guys who make a lot more than lions have no idea what a pointer is.
The day I understood pointers was the day I first heard the address -> house analogy. It still took me a while beyond that to really become fluent with actually deploying the C pointer syntax, and longer still to become comfortable with pointer arithmetic.
One extremely important fundamental point that I am very surprised you didn't mention: The reason why pointers have types to begin with. Void pointers (void*) exist because data is inherently typeless. Is the binary number 01001001 11001111 00000000 11111111 an integer or an unsigned integer or 2 shorts or 4 chars? There's no way to know by the data alone. You have to assign meaning to it. Incrementing/decrementing pointers (like `int a = 5; int* ptr = a; a+=1;`) can be confusing at first because the compiler uses the pointer's type to figure out how many bytes to increment/decrement. Incrementing an int pointer by 1 means "move the pointer by the size of one int (4 bytes)", NOT "move the pointer 1 byte". `a += 16;` == "move the pointer by 16 units of its type" == "move the pointer by 16*sizeof(a)_inBytes" == "move the pointer by 16*4 bytes" "Dereferencing a pointer" means to use the memory location that the pointer is storing, **then actually go to that location, returning the value at that location**. Example: int b = 64; int* ptrToB = nullptr; //Declare the pointer, initializing it to a safe NULL (but with pointer type instead of value type). ptrToB = &b; //Reinitialize the pointer. `&b` means "get the memory address of where b is stored". //Compiler determines the memory address of b, so we can't tell what it is without compiling. int valOfB = *ptrToB; //Dereferencing the pointer, which only ever happens after the pointer is declared ***and*** initialized. //valOfB == 64 **Memory is classified in bytes** and not 4-byte ints or 8-byte longs or anything else is because the *hardware itself is only accessible by entire bytes* (this is sometimes untrue, depending on the computer architecture, meaning sometimes the smallest accessible data is 4-bytes (some 32-bit architectures) or even 8-bytes long (some 64-bit architectures), both of them called a *word*). No modern computer can access each individual bit because that would require too much addressing-data. So how do we not waste 7 bits of memory every time we only need a single bit? Modifying individual bits requires pulling in an entire byte, applying bitwise operation(s) to the entire byte, then storing back the entire modified byte. This way, we can store 8 bools in a single byte instead of needing 8 bytes (but you'll always need at least one byte for a single bool). int a = 5; //ints are usually 4 bytes, meaning a=4+1=2^2+2^0 = 00000000 00000000 00000000 00000101 //The OS has allocated 4 contiguous bytes SOMEWHERE in memory to copy the binary version of the # 5 into. //The OS knew it had to allocate EXACTLY 4 bytes and not only 1 or 1,000 bytes because the compiler knows that //ints are 4 bytes. int* ptr = a; //Go to get the BYTE address that the int `a` will start getting read at. Anytime the pointer `ptr` is used in the future, //the compiler and hence the OS knows to read three more bytes after the initial address of `ptr` (4 bytes total). So, **why do we assign types to pointers?** It's NOT to tell the compiler the size of the pointer itself (which is always the same size on a given system, like how an int is always 4 bytes on the same system), BUT IT IS to **let the compiler know how many bytes to read after the pointer's stored location**.
I've been programming c/c++ oh since late 90s. Borland was my favorite compiler. Kept revisiting c and c++ to the point i got lost again. So many new features came along and i didnt keep up with the times. I didnt program at a professional capacity, embedded mainly. Ive tried many languages over the years, nothing bursts my bubble like c/c++, maybe because i have longer track record with them than others. I love being close to the hardware.
in my first course of C in college back in 1999 my teacher told us that pointers are the most important feature in C, then I started reading tons of books I could find in my college's library and coding multiple exercises in C with pointers, one of the books was Dynamic Memory Management in C. No one was getting those books from the library, their cards were clean when I borrow them, and even after I left the college I went back a few years later and checked the books and the only timestamps in those books were mine. Learning C, is the best way to learn about programming because teaches you the cost of everything in software, without any cheating, this is why I hate that colleges teach in python, to me is a terrible idea. I think there are only 2 valid main languages for teaching programming today, C & Haskell, then some dynamic languages like Common Lisp or Smalltalk, Prolog or Erlang, everything else can be learned in your own time, there are tons of tutorials in the web. But the languages that I mention are the ones that teach you truly important concepts.
About 25yrs ago, Uni course started with: Modula-2 (like Pascal) for data structures, logic & procedures; then C; a very basic example using assembler (equivalent of early RISC/x86 I can't remember using simulator); then some COBOL (yuck); then VB, simple LISP for logic; then OOP were just becoming popular; and then we could do some projects in whatever language we wanted.
@@alexanderheim9690Yep, we have something similar too. First semestre is C for basic understanding of memory, second is Java for OOP, then third is C++ that combines both. And some PHP and a little Prolog and such in the meantime and eventually Python and whatever else. I do think that it's good to start with C but I don't agree with the notion that higher level stuff like Python shouldn't be taught.
I started learning C++ when I was about 15 years old, just before starting high school, and having worked with PHP and JavaSceipt before that I breezed over the most basic stuff like variables, clauses, loops, functions, classes etc. Then I got into pointers and I got stumped for the first time since I started learning programming. I just couldn't get it no matter what kind of tutorials I tried reading and watching. After a couple of months I kind of got the idea but I never found myself using pointers in the simple programs I was writing. Then in junior year of high school, we started studying computer architecture. A part of it was memory - how the computer memory works. We were analyzing the architecture of the 8085 processor and when I sat down to study the material i finally got it - it was an eurika moment. It wasn't only pointers but a lot of other concepts became clear to me. Thats why when I start teaching someone programming, I start by drawing up a very basic scheme of a microprocessor working with a ram chip and explain how it addresses, reads and writes data from the ram in order to explain to them what exactly their code does in the background on the lowest level. Those who are able to get it immediately will have a much easier time learning peogramming and especially pointers.
Isn't it interesting how the human brain works? I've had similar experiences, yet different in some ways. For me, when I get stuck on something, I've learned to just walk away from it for a while, because always, I have a dream while asleep where whatever thing I'm confused on or didn't quite get, becomes clear. It reminds me of decades ago. I was writing a small-business app for a mom and pop shop. I forget what it was now, but back then, I got stuck on what some code should be and its math. I was literally stumped at that moment. I went to bed one night, leaving the computer running in the other room. As I slept, I was dreaming about my code. It was weird, because in the dream, the code was scrolling up and down, blurring the lines of code. Sort of like a spinning cylinder. Up and down, repeat. As it would spin up and down (lines moving up then down then up again) the scrolling was slowing down. When it slowed down, it stopped right at a line of code. You guessed it, IT WAS THE CODE THAT I COULDN'T WRAP MY HEAD AROUND!! I woke up right then, ran to the computer, found the position in code where that line of code should be, typed it in and YUP! IT WORKED! Since then, I've had many similar experiences where something that I found difficult to grasp, the answer was a nap away. LOL The brain is so interesting.
@BlondieSL Definitely, giving your brain a rest is the best thing you can do in order to learn or solve something that you just cant grasp. I work at a startup, and we get some interns from time to time. After the first couple of interns, I realized that there is one technology with which they all struggle and lose motivation - redux. Redux is quite complex to conceptually grasp, but it is really easy once you see the full picture. I had this one intern that just got stuck on it and wasn't moving an inch forward. I tried explaining everything twice, three times, asked him to watch me code, asked him to go over the documentation, and he just wasn't getting it. He went on a break for a week - a summer vacation. He came back to the office a week later, and I decided to start him off easy - a simple React todo application to warm up. He had it done in a few hours, and then I asked him to try and implement redux logic on the application. I was expecting him to get stuck and ask for help. I was shocked when about an hour later he said "done". I asked him if he was on a vacation or if he was at home studying. He said to me that the night before, before going to bed, he was dwelling on Redux, thinking about it constantly - he was visualizing the data flow, imagining the inner workings and what goes on behind all the function calls and suddenly he just grasped it. He doesn't know how it happened. He just said that he managed to connect the dots without having any code in front of him. Since then, whenever I am solving something difficult, I give it time. From time to time, I will try to visualize everything, write my ideas in notes, and after a week of this, I review all my notes and see if I have an idea or a solution. This works for me 9/10 times.
Free the mallocs! Awesome video. Pointers are always misunderstood and often not done properly, they get especially finicky when you start using classes and C++ conventions, like the Trilogy of Evil (Copy, Assignment, Destructor operators) where data inside pointers has to be handled, not just the pointers themselves. One thing I came across was that in classes, you can allocate memory space with malloc, but it will not call the constructor for you. Another thing I've come across a lot when debugging is that people will call delete on the pointer when it's freed, but you also have to set the pointer to null in order to not leak that last bit of memory. One thing that needs to be taught is how to clean up after your allocations (free() and delete/delete[]). I never learned this from three separate classes, until I went for a Game Development degree at Full Sail.
Yeah, took me about a year before I could write somewhat complex (and working) code using pointers. Back then it took repeated reading of K&R and tests to get my head around pointers.
What helped me grasp them was putting the asterisk next to the type, and mentally thinking of a byte or char pointer as its own type. So instead of reading "byte star pBkgndColor", I read byte-pointer-type pBkgndColor. byte* pBkgndColor; Silly, I know, but it helped make things click for me. In my mind having the asterisk next to the type makes much more intuitive sense.
For those of you like me where you started out with a scripting or higher level language and then decide to take on something like C/C++, it can feel scary like learning how to drive stick shift after you're used to driving an automatic. Everything is fine at first until you encounter pointers or the compiler starts yelling at you, sort of like how you're cruising along stick in shift but then start stalling out going up a steep hill or a railroad crossing. It will get better and two good advantages you guys have today that I didn't have in the past is online C compilers and Virtual Machines. It's a good way to practice all these concepts while still in a safe sandbox environment. 😎
Minor note. The examples used C++ std library features (eg cout), so technically you were using C++, not C. However since the discussion was about pointers that issue is sort of a minor trivia item.
I thought the same. Why make a video (good as it was otherwise) about C pointers and then use C++ features, when in C++ your "house" struct would have been a class? It's difficult to fault someone with this background and skills, but it did seem strange to me too.
Primary reason is that I wanted publicly accessible member vars for each access in the examples and structs are natively public whereas classes are private by default. And I wanted my pointer examples to be raw C even if the I/O scaffolding around them used C++
@@frubert123 everything in the video applies to C as well, just instead substitute printf for std::cout. Same goes in the opposite direction, just instead substitute typedef struct for a class with public member variables. Sure, they used C++ for the examples, but everything talked about is just the same for C, so it doesn't really matter.
@@frubert123It's very common to mix the two languages. I often do it. I work on legacy code that is mostly a mix of C and C++. I'm pragmatic. I do what works and code in whatever the existing style is and ignore the language lawyers.
Even though I come from TTL and then Assembly, I’ve always had inordinate amounts of trouble with symbology involving assembler-directives, figuring out other peoples UIs and pointer notation. 😢 Maybe I’ve been living on the ‘Spectrum’ all along 😂 Thanks for the video and clearing up some of the confusion with the notation! 😊
Almost forgot what pointers are ... been writing code in Java, C#, JS, Python for 20 years... Thanks for the refresher! The power pointers give is very much under-estimated.
I recently started teaching the introduction system's programming course at my university, and this should make for a great review resource going forward, thank you for this and the many great videos!
Best thing ever is function points, and pointers to arrays of pointers.. It makes huge stacks of case or if else conditions moot.. just makes an array that matches your data, and then stick it full of function pointers.. Instead of a lot of complex if/else or case statements.. it's just dereferencing the pointer and jump.. :)
Before I learned C I worked with assembler. As you can imagine I never understood how anyone may have problems with pointers. 😂 It is soooo natural! 😅 Pointer to pointer? Non issue... 😂
Wow! Dave, I hope to get your permission to use that video to introduce pointers to a lot of people, or to introduce a lot of people to the pointers ;-) Its painfully necessary these days!
The first rule of pointers (in any language that has them) is to design your code to minimize the need for pointers. Also, declare each variable on a separate line.
![[Full Episode] The Restaurant War Thailand ศึกพ่อค้าซ่าแม่ค้าแซ่บ Episode 1 | 22 ก.ย. 67](http://i.ytimg.com/vi/BuzQ70v-UZQ/mqdefault.jpg)
Yea this guys been coding in C longer than I’ve been alive. I’m going with this guy.
You look exactly like a person who would teach me about pointers. Just like a Wizard NPC in games.
What kind of statement is this? 😂
@@itsSpidey- he is saying that dave's appearance exudes competence and advanced knowledge of the subject
Its dangerous to go alone, take this pointer!
You shall not pass!!! (by value)
That analogy between memory address and the address of a house is great! I used to make similar comparisons when teaching C to students and it really seemed to help make it click for them.
I'm 12 years into programming now... And i just understood the concept now, with that analoy :D
as if you never heard that analogy before. that analogy was in every tutorial I've seen.
Dave, i have been coding in C since 1980 and have, many times, tried with variable success to explain pointers to newbies. This video is clearer and more concise then my best efforts. Going forward I'm just going to refer newbies to this. Thanks.
Hope it helps others!
These three sentences solved the big problem I was having when learning pointers: "Depending on the size and complexity of the house structure that could be an expensive and wasteful operation. Why is it wasteful? Well because just like in real life there's no reason to bring your house to the appraiser for an appraisal the appraiser comes to you."
I was always so confused as to why you would use pointers when you could just carry the whole object around. But because it copies the entire house variable, which is often more data than a 8 byte pointer, this makes it efficient to use on any item that is larger than the size of a pointer. Thanks a ton!
Also, if the function you passed the House to modifies any member variable of the House, the original House that you had will not be the one that gets modified -- instead, the copy (which will be thrown away when the function is finished) is the one that gets the changes, which is probably not what you desire to happen. Using a pointer allows the original House to be modified, which is probably the expected behavior.
what about the cache though? what if that can cause some kind of memory miss, wouldn't you be paying a CPU cost or something?
One of the best exercises I ever did was learning to setup a 2D array in one malloc, so that it can be accessed by array[row][column]. I don't think I really understood pointers until I did this. If that's easy for you, do a 3D array. If that's easy, you are good at pointers.
Its a great video if you understand pointers but it fails to do the most important part of why people don't understand pointers. People don't understand pointers because they don't understand the problem they are solving.
The moment you understand how memory works, how data is stored/loaded in/from memory and what the cpu has to do differently depending on if you call by reference or by value is the moment you get pointers. The real explanation needed is not what pointers are but what problem they solve and why you need them.
Back when i was learning C i had a hard time wrapping my head around pointers until one day my boss took an houre to explain the difference. He showed me the assembler output of different scenarios with and without pointers and explained what happened on each line inside the cpu and memory and it just all made sense after that. It's not about what pointers are but what problem they solve and how.
Assembly is a lost art, but explains so much.
this
Yeah assembly could have explained it simply..
You have Registers, and direct/indirect addressing…
all registers can be pointers unless they all are general purpose registers
Then the addressing and instructions decide how we are representing the registers
LA R1,=A(0000) Load address of location where =A(0000) has been resolved in the executable, into Register 1
XC 4(256, R1), 4(R1) XOR 256 bytes starting from values pointed by R1 offset by +4 bytes with the same… (XOR of itself is 0 ie clearing all the bits/bytes at that location)
ST R1,INT32 Store value in R1 into location INT32
L R3,INT32 Load value at INT32 into R3
LA R4,INT32 Load absolute address of symbol INT32 into R4
ST R3, 0(R4) Store R3 into INT32 symbol location
INT32 DS 4F
Someone who knows assembly should be able to teach pointers in a better way
Wow, 40 years ago I was still programming Fortran and had never heard of object oriented programming. At the time I was designing a production program to run various tests on pacemakers and since all the tests had some shared behavior (like limits checking, saving results to a database, printing results, etc.), I decided to create a large common block array that was indexed by something I called a "test number" then functions could do what they needed with just a test number. One huge advantage was that I could configure what tests to run and what limits to use and units to report with a big constant array at the top of the code. This meant that when a new test specification came out, usually all I had to do was to change the constant array and no code change was required. Later on in my career my SW boss told me I had created Object Oriented Fortran. Interesting - I was just a young "lazy" programmer trying to find a way to do more with less code to develop, debug, and validate. Also, being ADD, my brain worked faster than my fingers.
Haha, all programmers are lazy; this is what drives the development of technologies, languages and so on!
@@tangiblewaves3581 well i agree but i dont agree, i think we always find shorter ways to do things and yes we develop wicked tech from it, but programming its self can be very intensive / labor intensive. And takes a lat of work even to learn, so i get what your saying, but programmers are just like any trade (plumbers, electricians) and just like those trades look for better ways. I have a family full of trades, and they are full of unique (what i would call lazy) ways to fix stuff but it works and they have good solid reputations for the work they do, sometimes its those ways that make a completely new product that works 10x what the previous method is, but it takes knowledge and the skill to think it through (and sometimes the balls to apply the fix lol and hope it works.) just like them, programmers, designers and scientist need to sometimes "go back to simple" in order to step forward. All that said... i have seen lazy programmers and lazy plumbers. so i think the ratio is likely the same in terms of avoidance of physical labor. o7
@@NanoGameLab exactly, and if you want to code proffessional, you also need some good amount of discipline to code even when you have a bad day or are tired.
Cool story.
A good programmer is that who will spend 3 hour of his time to automate a one time task that requires half an hour to be made manually.
Pointers were so logical and intuitive for me. When I was first learning C++ I was coming from having played around with languages that didn't have dynamic allocation, I didn't know what dynamic allocation was at the time but I had been frustrated in numerous projects I had made that I couldn't make new variables at runtime. So when I first read an example of malloc and using a pointer I immediately put down the book (before even reading the explanation of the example) because I had recognized it as the solution to what I had wanted for so long and wrote a linked list (not that I knew that it was a linked list at the time) to verify that it could do exactly what I had hoped it could, and it worked. I was so excited, the possibilities of pointers were limitless in my eyes and I messed around with them for most of the rest of the day.
When I finally got back to reading the book that I was using to learn C++ I was a little disappointed to learn that everything I thought I had created to use pointers for was pretty much covered in the next chapter, but I was glad that at least I had understood them well enough that I could correctly extrapolate their uses without knowing much more than that they existed. It also turned out the example was only the first half of the program that only covered allocation, it wasn't until I turned the page to see the deallocation example and read the explanation for it that I realized all the horrors of memory leaks and how many I must have created that day 😉
"having played around with languages that didn't have dynamic allocation"
Cobol ?
@@IBelieveInCode Logo and Visual Basic, though I was very young at the time and no internet so I might just not have been aware if they actually did have that capability.
Honestly i don't have any problems at all understanding the concept of pointers, all that makes sense to me. What i don't understand, is when you want to use them
Maybe that is the right way to tech the concept, is to pose problems that require the indirection to do the job. A lot of things are easy if the person thinks it was their own idea or something they want rather than something imposed from outside. Get them to say for themselves "what I really need is some way to ..."
@@TehIdiotOne as said on this video, the most common use is with larger or variable data types like objects, it is much more efficient to point to the adress of an object than bring the entire object into memory, this is especially noteworthy in C++ when storing lists of large objects or integers, you just use the pointer and the -> operator and it is way more memory efficient. Plus, it allows for dynamic memory allocation which allows to manage what is and what isn't in memory at any given time
This is the most amazingly coherent, clear and informative explanation of pointers I have seen in 14 years since I started programming in C and C++. This is beyond fantastic omg please continue. :)
I've been (slowly) learning C as my starting language just for fun. Pointers has given me many headaches and I still can't completely get a picture in my head of how they work. I wish sometimes that they had a special name or different symbol, maybe that would've made it easier. But you mentioned a few things (that I had to listen to 3-4 times) that gave me some better insight, so maybe one day. Thanks!
Making a drawing of it often helps a lot.
Hang in there! You'll understand them 👍
C and C++ learning is like this: you learn the basics and start writing. Then you want to do more or understand someone else's code, at that point you go through 3 to 6 months of FOG where you don't quite get it, but you keep trying. The good news is once you get past that, you become a decent programmer.
@@newmonengineering I basically set out to make a reasonably simple game and by using reference code from others or books I've managed to piece things together bit by bit. By interpreting compiler errors I've managed to kind of get a feeling for when it's in need of a pointer or not. So I definitely know more now than half a year ago luckily :)
I think C started a bad pattern for working with pointers because you declare one with the same symbol you use to dereference one. That said the arrow operator has some, as of yet untapped, potential for conveying ownership semantics needed for automated resource management (at the cost of the control C devs freak over :p)
Two follow-up tips:
The & (address-of operator) is used when you want to turn the address value of something into a pointer. Second, you will sometimes see that asterisk * in different places between the type and the pointer name: e.g. int* a; int * a; int *a; int (*a); ... all of these are exactly the same. The whitespace doesn't mean anything in these examples. That took me forever to understand. Just try to be consistent in code.
int* should be the only way to write int pointer.. everything else should be banned 😄😄
To me it makes the most sense. The type is an "int pointer" so put it with the type name... I think it's confusing for beginners because it looks similar to the dereferencing syntax.
@@JamieT1986 yes, but then a declaration in 4:07 would create 2 pointers, not one. int * x, y is in actuality: int *x AND int y.
I agree it would be better to just have something like 'intP x, int y' and then it would be obvious what is a pointer and what isn't but we got stuck with a syntax that is efficient for writing, but hard for reading - somewhat opposite to Python's syntax.
@@vaakdemandante8772 int* x, y; is something I was a little skeptical about actually when I saw this. I never knew that's how it worked, and I forgot to test it myself. I will assume it's correct... but yeah that kinda screws it up! :)
"int \*num" is much better, the declaration in 4:07 is confusing if you use the "type\* var" version.
Edit: I used "\" sign cuz youtube comments converts asterisk to bold letters. lol
This^^^ i would say, find a style and stick to it, but as an OS and firmware dev the most common style i come across (and use personally) is this:
Type* var_name = ….whatever here….
Ex: int* pointer_to_integer = (int*)malloc(sizeof(int));
So the asterisk essentially lives right next to the type, with no whitespace between. This makes it clear that it is a POINTER of said type, in my example a pointer to an ‘int’
Using this style consistently makes reading and reasoning about pointers much less frustrating in my opinion.
Of course, then there is dereferencing a pointer to get the object’s value. In those cases common style i see and use is this, continuing with my int example:
int integer_variable = *pointer_to_integer;
So we use the asterisk right against the VARIABLE NAME to dereference it. The combination of sticking to these two basic style guidelines makes points way less messy.
Essentially, use the asterisk directly next to your type name when declaring a pointer variable, and right next to the variable name when de-referencing it. Hope this helps some of the less experienced!
Also, as a follow up, i think the example at 4:07 of
Int* x, y
Is a kind of poor example. It just isnt code that would fly in most (well maintained) C projects like the linux kernel for example. You want things to be CLEAR above all else, and so its not really much effort to be explicit with each variable declaration. The compiler can optimize for you if it is necessary or possible. Otherwise, be more verbose in an effort for future contributors to have an easier time grasping what your code is doing. Little syntax tricks like that can be neat, but often fall flat in well maintained project environments with C.
i was a TA for an intro to C class, and the house example was what i used to describe pointers to people really confused about them. glad to see that you are using a similar example here! i feel that the easiest way to describe technical concepts to people who are confused about them(or have no technical experience/knowledge) is to use a real world analogy, even if it oversimplifies what is actually going on. once they understand the analogy and how it relates to the technical concept, then they can get to the nitty gritty of understanding the technical details behind the concept
This is my 4th time learning C and pointers in 32 years, and this is probably the best explanation of pointers I've ever heard. Although maybe thats because this is my 4th time learning pointers. Who knows, great video none the less sir!
I started learning Turbo Pascal in the mid 90s, so for me pointers where never really hard to grasp as TP uses them too.
Once you have the concept in your head a pointer to an array of pointers becomes a natural thing to work with.
Great video!
We are that old, eh?
I first used pointers in Pascal on a mini computer in the mid 80s, and then Turbo Pascal in 1986, although I was also an assembler programmer before that, where you use pointers all the time but call it indirect addressing. Pascal taught me about structures.
Then I went onto C, but it was K&R, and I found the nomenclature hard to follow: it took me months to get proficient, not because I didn't understand the concepts, but because K&R C can be super impenetrable for a C noob. Thankfully ANSI C came along at just the right time, I re-wrote the K&R code I was maintaining in ANSI, and I've stuck with that ever since.
C remains my language of choice to this day, but mostly I'm a deeply embedded systems programmer and mixed signal hardware engineer, where C sits well, nice and close to the hardware. I dip into assembler still every now and again for those pinch points, but 99% is C.
@nezbrun872 I literally use Delphi for fun nowadays, with a free Community license. It's pretty fun tbh
On the first example, it is important to note the memory address needs to be casted to a byte pointer. When I was learning, this confused me a bit, especially when working with custom types. You can have an entire buffer filled with data which looks random, but if you cast it to the correct type when dereferencing, all values in the custom structure are magically decoded, and it is extremely fast!
You're right, I remember "struct IntuitionBase * pIntuitionBase = (struct IntuitionBase *) LoadLibrary(:...)" is what threw me the first time!
@@DavesGarage We really needed the modern version of the auto keyword back on the Amiga. 80 columns only go so far.
Because i guess you did not start with assembly langauge. This was my 2nd language after Basic .... like all teenagers in the early 1980s home computer time. Feeling sad for the current generation that think it's not only magic but black magic.
@@llothar68 actually, in my Electrical Engineering curriculum in 1999 I took a class in ANSI C in Unix and an Assembly class. In the Assembly class I wrote a 8088 CPU emulator, which was both frustrating and fun! I ended up using assembly programming PIC microcontrollers more than anything else. I used the term “magic” because I know what it is doing under the hood for me, and how much effort the C language saves us rather than writing in pure assembly! Cheers! Edit: it was the 8080, not the 8088-long time ago and I have lost the floppy disk where I had a backup. Oh well…. My degree is in Electrical and Computer Engineering (ECE) and I took quite a bit of digital design classes, focusing more on hardware than software.
@@llothar68 im self taugh software engineer, i did not went to cs, and I know this stuff, cause I love digging deep, no need to feel sorry. most of these jobs doesnt require this knowledge, yo ucan still learn it as hobby
30 years ago I learned about pointers in C, and I’m grateful for this recap. Some things made more sense even now, after watching this, particularly the double indirection.
Starting with C and fiddling with memory made understanding how more higher level language handle memory / what is passed by reference vs value.
Pointers, and pointers to functions, are a powerful tool. My C programming days are over (now Python), but using these tools with data structures (linked lists, queues, trees) is indispensable. Great topic, and well taught. 😎👍
5:41 The -> pointer "dereference operator" is the shorthand variant for (*struct_name).member e.g. (*pHouse).SquareFeet
11:00 Usually when we program in C without classes ,we are using malloc. In C with classes (C++) we use new. Syntactically are both correct but new is safer.
2:58 Hardware registers or memory locations (physical memory locations on a CPU without MPU/MMU) can be accessed using a single line of code like *(byte *)53281 = 0x00;
"Usually when we program in C without classes ,we are using malloc"
It depends on the platform and application: in embedded microcontroller applications, which are typically memory constrained. would fail catastrophically in the event of failure, so malloc is rarely used in production hardware. As a result, memory and objects are typically allocated statically, or on the stack (typically small objects only on the stack).
Calling C++ “C with Classes” is sort of like calling Firefox “Netscape Navigator”. Or maybe like calling Windows “MS-DOS 1.0”.
@@danielrhouck It is something common among C (ansi, K&R, 90, etc) fans.
@@JohnDoe-kh3hy Classes are one of the *many* things C++ does differently than C, and they are *not* the most important one to this discussion.
@@danielrhouckNot really. Stroustrup referred to C++ as "C with classes". If it's good enough for him, it's good enough for me. It's a nice succinct way to describe the language conceptually.
Good video, Dave. I also have been working in C/C++ for about 40 years, including work for some notable compiler vendors such as C86, Zortech C++, and GCC (via Cygnus).
This was IMO an uncommonly clear and well-organized presentation. Was impressed that you had time to include pointer-to-functions in this 14-minute overview.
Perhaps you might have mentioned the precise prototype matching required to do real-world useful work involving pointer-to-functions; and in particular, how judicious use usually warrants declaring a typedef for a particular group of related pointers-to-functions.
Dear Dave, you said something really wonderful. When you want to learn C++ or C but your first language is Python, of course, it looks scary. That is what I can hear from a lot of students who are honestly scared to delve into low-level languages and learn how "motor" actually works. Since I am a child of the 80s, my first language was machine code and assembler for 8-bit CPUs. As such, I always try to explain things from that perspective, emphasizing memory and how the CPU "crawls" through it. Thank you for this episode. I truly believe it is important. Greetings from the Netherlands.
As a veteran assembler and C programmer of over 45 years, I can tell you that Python is scary to me. I seem to spend more time maintaining a working development environment than I do writing code in Python.
@@nezbrun872 That sounds kind of disgusting. I've never dived into Python. I started with C64 BASIC and jumped to machine code after that. A few years later when I got into college I got introduced to Pascal. After that I pretty much went into C, because I was fascinated with MUDs and wanted to learn how to run one and modify it.
I was once in a class where students first learned Visual Basic and then moved on to Java. And I can say that Dijkstra was right, learning this way actually harms students.
@@nezbrun872 Dear, I totally agree with you. You have less control on data flow. Young people who are using languages as Python, then just don't think about memory, about what is going on behind.They rely on some, what they call - libraries, but it is more like the whole Lego block, framework. For me library is part of the OS or what I build for myself (: I'm glad there are more people who feel the same. Thank you for sharing!
@@TheAndjelika ...and this is why my windows machine uses 7GB of memory after just booting....
[C]lear and straight to the point(er). 🎯
6 years of college working in C++ and i had never even heard about function pointers, thanks for showing me something i didn't even think was possible!
Function pointers are kindof the origin of object oriented programming. You would create a struct with function pointers as member variables. Then a "constructor-like" function could initialize the struct with the desired functions and voilá you have a class. C++ started out as a transpiler to C and, I might be wrong on this part, that is how i think it translated c++ classes into c structs.
Function pointers are currently almost not used (directly) in modern c++ (of course they exist and can be used if needed): most of the functionality was moved into lamba/function objects which is more robust and powerful solution (with some small problems). Also operators new/delete should not be directly used (as smart pointers are better option with make_shared and make_unique templates).
This video is exactly what I was looking for to help me improve my programming skills. Thank you for making it!⭐♥
BYOB - Bring Your Own Bytes?
Hands down one of the best and concise explanations of pointers! It seems to all click in place after using and avoiding them all these years!!!
Holy mackrel
I don't think I ever rewatched a single video consequtivelt as this.
Sir, in 12 minutes, you explained pointers better than my professor in an hour and a half.
I first toyed with C a year ago and was so confused by pointers. Learned a lot here!
Thanks for making this video! I still remember the exact ‘ahah’ moment (two decades ago in freshman cs) when I grokked c memory (pointers, arrays, structures). Learning how c handles memory really helped me understand how computers work.
Thanks Dave for revising my C concept. Last time when I did was solving exercise of K&R in 1 st year of graduation. Clap for your line "I am not here to sell anything".
Been doing C/C++ for 30+ years. Think I started C when I was around 15 or so. Pointers were fairly easy in terms of grasping the concept. I had to figure out pointers to pointers on my own as I was writing a DOS tilemap level editor for a game I was working on. I wanted the menus to be dynamic and each menu item (string) varied in length and the menus could have a variable number of items, so pointers to pointers it was.
It doesn't really get messy until you're doing weird multiple level casting and de-referencing. That usually trips me up if anything.
I hit "thumbs up" on the video for the thumbnail alone, lol.
You can also subtract a end pointer from a start pointer to get the length of data or string.
As for void pointer if you use the same format for all your structs then a uin64_t in the beginning can be used to identify the data type.
Working in assembly will really make you appreciate pointers. The scary part of C and C++ are all the special characters, it just looks like you could hurt yourself, which, you can. C teaches you to have good habits, if you are using it for production code where YOU get the call at 3:00 AM if it crashes.
Indeed. I wish I had known, and perhaps should have said, that a pointer is very much like zero page on the 6502.
Coming from IBM assembly with it's base address + offset instruction format, C/C++ pointers were a piece of cake. Anyone remember the USING or CSECT directives? Fun times.
My experience with pointers came with my first programming being PDP-11 assembly (school) and later 6502. So dealing with them in 'C was very straightforward...after the syntax of course. I say that because your comment about 'decorating the variable' rather than the type, (int* x is not int *x) was my personal stumbling block.
My first language was BASIC (GW-BASIC and QBASIC) and Visual Basic. I had heard about how scary pointers were, so when I learned C in grade 11, I made sure to pay close attention to the lesson on pointers. And... they didn't seem so scary. Suddenly a bunch of things about C (and even BASIC, to some extent) made sense. Later, I would sometimes get confused when working with double and triple indirection, but generally pointers never seemed too difficult. I think it was that moment that I realized I was meant to be a software developer 😆
Good for you. I think pointer fear is the result of insulation from it in some modern language contexts. Anyone used to assembly / low level C coding would have no such fear because it's absolutely certain that they would have to have dealt with it from day one.
The Aha! moment here is pretty fun. Pointers aren't necessarily as confusing as their use cases are not very intuitive for a new student.
The house address analogy does wonders for assignment and copy constructors, though! In C++, making a copy of a house to show someone what it might look like is an incredibly vivid idea for me.
The very first programming language I learned, back in 1995 when I was 11 years old, was C. I had to tackle pointers from the get go, and of course they were a difficult topic for a child to grasp initially. But it made a HUGE difference for me when, years later, I started learning more high level languages such as Java, C#, and Ruby. I was WAY ahead of my colleagues who were learning those as their first programming languages, as the internals of what we were doing were much more intuitive for me.
Dave, I've been watching your channel for a while now, you might not read this, but I found this video very interesting. I started to learn to code several years ago, and got stuck in tutorial hell in several language. C is the first one after many years I've actually stuck with. I guess my brain is wired different, so the features of a lot of the new languages have too much abstraction for me. I like to know how things actually work, and C has been a huge stepping stone for me to finally get into software engineering. It's been more of a hobby for me, but I would like to do something involved in it whenever I retire from the military God willing. I understand hardware very well from my background of troubleshooting, and working on weapon systems that employed digital electronics, radar theory, signal data conversion etc, but programming was always a mystery for me, it sounds stupid I guess, if I can grasp hardware, software should be easy. Thankfully C exists. My question to someone with your background, is there a good method of connecting with people other than reddit, that could help with pointing to resources to expand my knowledge on C and the data structures/algorithms that are needed to be learned in the industry?
Thanks! Very Helpful. You explained some things that C++ books that I have read have overlooked. Like ..... The reason why we even need to use pointers to begin with. I hope to see more content like this.
I learnt about pointers in high school. Having programmed in a higher level language for the next decade or so I really never needed them except for knowing they’re really what's used under the hood for all the syntactic sugar I grew accustomed to. What clicked for me was when, trained to use polymorphism I tried to obtain the same result in c++ embedded only to realize you cannot send daya structes of different sizes to same function. Using pointers was the solution for passing different implementations of an interface of varying byte sizes.
The 53281 example made me nostalgic. I've only recently started coding in C, but so far pointers have seemed pretty logical to me, maybe because I grew up on constantly referencing specific addresses in memory on the C64.
I figured it'd be meaningful to a few folks :-)
Hi Dave, I discovered your channel a few days ago and enjoyed some windows related vids; today I wanted to improve my understanding of C pointers and, voila, here you are again! I looked at some other tutorials, but yours is definitely the best! I really love your style! Keep up your great work; it's pure gold! ❤
I recall a textbook that described the pointer, and then said, "At this point, the point of a pointer seems quite pointless." They aren't, but the line was good.
I once had to create an array of function pointers. I remember nearly going blind with the syntactic gynastics that was required to create the thing and actually use it without leading to memory leaks. That was some 30 years ago, when I was programming embedded systems. Anyways, I strongly agree that mastering pointer syntax is important to improve your code READING skill. Oh, yah, and I heavily commented all that code. I typcially had more comments in my code then code, but I recall going way overboard commenting that code.
Excellent! My best saga was creating a pointer to an array of functions (oh what fun) 😆
Wow. This made a whole lot more sense to me by the end. Thanks Dave!
I understood the point of pointers when I tried to access registers in a microcontroller. And to this day it makes the most sense of using them.
Very clear introduction to the most important things about pointers.
Remember struggling a lot with those when I started using C++.
Function pointers are very useful in things like emulation. Setting up an array of instruction codes, with the value being a pointer to a function is much more elegant than a massive switch block (plus you can easily add placeholder functions that haven't been implemented) 😁 It's also handy to cast pointers to different types for performance. For example if moving a large array of 8 bit ints (e.g. RGBA data from a buffer) to another location (like display memory), you can cast to a 32bit or 64bit int pointer instead and move blocks of 4 or 8 at a time, and only drop down to 8 bit for the last few.
They are also the basis of how member functions really work in C++. It is possible to create your own system of "Virtual Method Tables" in the C language to get very C++ like operation in a place where it is needed. Your array of pointers to functions that carry out operations is a type of VMT. You could make a different micro being emulated by making a new variable with a pointer to a different VMT as part of its structure. Thus you can make the version of the micro controller with no multiply and the one that does a multiply and switch in the right one.
@@kensmith5694 Ever since I started programming C in C++ I've realized how terrible virtual classes are. Creating a struct with function pointers is infinitely more flexible than the limited tools C++ gives you and it's so much easier to understand.
@@smushy64 Virtual member functions can be a good tool but sadly it is a round hole that many try to fit a square peg into. The design of C++ kept some mistakes from C and then added some new ones. The C++ library also contains some fairly obvious mistakes that now programmers must live with.
I made the jump to C from Assembly, somewhere in the eighties.
Pointers are trivially easy to understand if you know assembly.
Damn for some reason I couldn’t pick this up in university but the way you’re explaining it finally makes sense lol.
Excellent!
I am coming to C++ and Rust from other linguages both compiled/assembled (primary) or interperted. (50+ years in programming -- livelyhood/ hobby to retired and just hobby).
If this is a topic that should be explained:
o Coding: Best Practices, with emphasis on:
- Readability via Logical Format (after or along with the comments to explain)
- Preventing Memory Leaks
> Tools Available To Check - if such a thing exists
Links to, if this is something best explained by examining what you consider good coding practices.
Programming helps keep my mind sharp. Plus I just love it. When working I got paid for what I would have done for free (well almost). Looked up and it was time to go home. Couldn't wait to get back to where I left off.
Thanks again,
Feels like a PBS documentary. love it.
We use pointers for everything at work. I mean EVERYTHING. Network structs? Passed around everywhere as pointers. Passing around random data structures that you don't define until runtime? Void pointers. Needing to access a player and all their information if building video games? Pass around const refs to the player
Online course sellers hatehim! Man shows up, explains the important things and crashes a whole 15$ course industry!!!! Actually I never understood half the things you talked about because I was reading about them on stackO or those CS50 notes. Thanks a lot!
Thanks for your programming content! I have been a programmer for a while but nowadays information technology seems much too complex for me. I cannot code for real but I can follow your explanations and understand them. It's just I have problems memorizing them. So I consider your videos a source of sophisticated entertainment.
:P Man I feel so smart for once, after 23 years of hobbyist programming in C/C++ I knew all these tips!
aaaaaaa, so malloc returns the void pointer and that is why we almost always cast it to our type... perfect, thanks Dave! I learned something new!
Exactly! That cast to (byte *) 53281 is needed because you can't assign an int to a pointer without it.
@@DavesGarage Thanks Dave, main.c:7:5: error: unknown type name 'byte'. People often use unsigned char, what do I miss?
Thank you for the video.
Please make a complete tutorial of C and C++.
You have TON of knowledge and experience I would love to learn from you.
Thanks for the pointers, Dave!
I don't think I ever had an issue with what a pointer _is_; however, the syntax around the implementation is where I still get confused from time to time. (It does not help that I've only ever used C/C++ on an as-need basis.) IMHO, the most difficult concept to understand is using the star operator to declare a pointer but also to deference said pointer later. The second is the arrow operator - more to the point, when to use the arrow operator vs. the dot operator when dealing with structures. This latter issue becomes even more fun when you have pointers to structures which include arrays or other structures, where you now have the arrow operator and dot operators both to ultimately access some member of the structure. Your video really helped me here - I never realized that very important distinction, and I really appreciate your explanation. Love your videos - keep them coming :)
When it comes to understanding the reasoning behind the way pointers are declared in C, the best explanation I've heard is that you read from the variable name to the right and then to the left, so
int foo; // foo is an int
int *bar; // bar, when dereferenced, is an int
int (*fn_ptr)(int, int); // fn_ptr, when dereferenced, and when called as a function with two int parameters, is an int. Alternatively: fn_ptr is a pointer to a function that takes two int parameters and returns an int
Thanks, Dave! This is what I'm talking about! Coverage of more advanced C/Cpp topics. Please keep up with explaining some applications where the topic-of-the-day is used. I will say again, your knowledge should be memorized in a book. I would buy two!
The general concept of pointers has made sense to me for a while, but I've struggled to follow examples that use them or design my own programs.
I think your video explored them from an angle that finally made a few things click for me, learning to use them effectively will still be a task but I think I can see some of the patterns now lol
Picked up writing some code for microcontrollers, my C is a bit rusty so these video's are very welcome.
Had this discussion over and over and over again with people saying the C/C++ is dead because of pointers. I'd love to work on a project again where C++ is used in the back and front-end. It is the most robust way to program anything. Anyone that doesn't know how to program in C or C++ and how to work with pointers is a "Kiddie scripter" 🙂
Get into resource-constrained embedded systems where we still care deeply about memory utilization, raw performance and power consumption. Almost all of it's still in C, and written bare metal.
You can write great C++ without pointers, which is the focus of my episodes on shared_ptr and unqiue_ptr
@@DavesGarage Yup. Already watched it. And yes, I've used auto_ptrs and then later the shared_ptrs from boost. This is, of course, now part of the standard library. unique_ptrs replaced auto_ptrs. shared_ptrs are quite convenient for resource sharing across multiple objects and threads
Once the light bulb went on in my head, it was mind-blowing. I was obsessed with it for months afterward.
Starting on the commodore 64 where everything was done with poke greatly aided the lion kingdom's introduction to C. Of course, younger guys who make a lot more than lions have no idea what a pointer is.
Who could teach you better than a gentleman made his hair white on programming? Absolutely no body 🙏🙌
I have always struggled with this. Dave, your explanation is the best I've ever heard and it worked for me! Like you say "it clicked"!
Liked the parts where you shared why we would want to use pointers. Like the malloc api context was good to learn about.
Also too, (kept in my mind) the stack on 6502 is so small you could never pass a struct like item to a function with anything but a pointer.
The day I understood pointers was the day I first heard the address -> house analogy. It still took me a while beyond that to really become fluent with actually deploying the C pointer syntax, and longer still to become comfortable with pointer arithmetic.
Damn, I thought the house address analogy was original! :-)
One extremely important fundamental point that I am very surprised you didn't mention:
The reason why pointers have types to begin with.
Void pointers (void*) exist because data is inherently typeless. Is the binary number 01001001 11001111 00000000 11111111 an integer or an unsigned integer or 2 shorts or 4 chars? There's no way to know by the data alone. You have to assign meaning to it.
Incrementing/decrementing pointers (like `int a = 5; int* ptr = a; a+=1;`) can be confusing at first because the compiler uses the pointer's type to figure out how many bytes to increment/decrement.
Incrementing an int pointer by 1 means "move the pointer by the size of one int (4 bytes)", NOT "move the pointer 1 byte".
`a += 16;` == "move the pointer by 16 units of its type" == "move the pointer by 16*sizeof(a)_inBytes" == "move the pointer by 16*4 bytes"
"Dereferencing a pointer" means to use the memory location that the pointer is storing, **then actually go to that location, returning the value at that location**.
Example:
int b = 64;
int* ptrToB = nullptr; //Declare the pointer, initializing it to a safe NULL (but with pointer type instead of value type).
ptrToB = &b; //Reinitialize the pointer. `&b` means "get the memory address of where b is stored".
//Compiler determines the memory address of b, so we can't tell what it is without compiling.
int valOfB = *ptrToB; //Dereferencing the pointer, which only ever happens after the pointer is declared ***and*** initialized.
//valOfB == 64
**Memory is classified in bytes** and not 4-byte ints or 8-byte longs or anything else is because the *hardware itself is only accessible by entire bytes* (this is sometimes untrue, depending on the computer architecture, meaning sometimes the smallest accessible data is 4-bytes (some 32-bit architectures) or even 8-bytes long (some 64-bit architectures), both of them called a *word*). No modern computer can access each individual bit because that would require too much addressing-data.
So how do we not waste 7 bits of memory every time we only need a single bit? Modifying individual bits requires pulling in an entire byte, applying bitwise operation(s) to the entire byte, then storing back the entire modified byte. This way, we can store 8 bools in a single byte instead of needing 8 bytes (but you'll always need at least one byte for a single bool).
int a = 5; //ints are usually 4 bytes, meaning a=4+1=2^2+2^0 = 00000000 00000000 00000000 00000101
//The OS has allocated 4 contiguous bytes SOMEWHERE in memory to copy the binary version of the # 5 into.
//The OS knew it had to allocate EXACTLY 4 bytes and not only 1 or 1,000 bytes because the compiler knows that
//ints are 4 bytes.
int* ptr = a; //Go to get the BYTE address that the int `a` will start getting read at. Anytime the pointer `ptr` is used in the future,
//the compiler and hence the OS knows to read three more bytes after the initial address of `ptr` (4 bytes total).
So, **why do we assign types to pointers?**
It's NOT to tell the compiler the size of the pointer itself (which is always the same size on a given system, like how an int is always 4 bytes on the same system), BUT IT IS to **let the compiler know how many bytes to read after the pointer's stored location**.
Let me speak from my heart =) This description was absolutely incredible! I wish I've had it about 5 years ago..
OMGZ Dave, you spilled the beans on how to blow up the internet by calling random points!!!
I've been programming c/c++ oh since late 90s. Borland was my favorite compiler. Kept revisiting c and c++ to the point i got lost again. So many new features came along and i didnt keep up with the times. I didnt program at a professional capacity, embedded mainly. Ive tried many languages over the years, nothing bursts my bubble like c/c++, maybe because i have longer track record with them than others. I love being close to the hardware.
Honestly maybe the reason I'm into C++ so much is because there is a never-ending stream of videos about it 😄
Ha ha !
in my first course of C in college back in 1999 my teacher told us that pointers are the most important feature in C, then I started reading tons of books I could find in my college's library and coding multiple exercises in C with pointers, one of the books was Dynamic Memory Management in C. No one was getting those books from the library, their cards were clean when I borrow them, and even after I left the college I went back a few years later and checked the books and the only timestamps in those books were mine.
Learning C, is the best way to learn about programming because teaches you the cost of everything in software, without any cheating, this is why I hate that colleges teach in python, to me is a terrible idea. I think there are only 2 valid main languages for teaching programming today, C & Haskell, then some dynamic languages like Common Lisp or Smalltalk, Prolog or Erlang, everything else can be learned in your own time, there are tons of tutorials in the web. But the languages that I mention are the ones that teach you truly important concepts.
About 25yrs ago, Uni course started with: Modula-2 (like Pascal) for data structures, logic & procedures; then C; a very basic example using assembler (equivalent of early RISC/x86 I can't remember using simulator); then some COBOL (yuck); then VB, simple LISP for logic; then OOP were just becoming popular; and then we could do some projects in whatever language we wanted.
In my uni we start with C and haskell in parallel, then we do java for object oriented programming. I really like that arrangement.
@@alexanderheim9690Yep, we have something similar too. First semestre is C for basic understanding of memory, second is Java for OOP, then third is C++ that combines both. And some PHP and a little Prolog and such in the meantime and eventually Python and whatever else. I do think that it's good to start with C but I don't agree with the notion that higher level stuff like Python shouldn't be taught.
I started learning C++ when I was about 15 years old, just before starting high school, and having worked with PHP and JavaSceipt before that I breezed over the most basic stuff like variables, clauses, loops, functions, classes etc. Then I got into pointers and I got stumped for the first time since I started learning programming. I just couldn't get it no matter what kind of tutorials I tried reading and watching. After a couple of months I kind of got the idea but I never found myself using pointers in the simple programs I was writing. Then in junior year of high school, we started studying computer architecture. A part of it was memory - how the computer memory works. We were analyzing the architecture of the 8085 processor and when I sat down to study the material i finally got it - it was an eurika moment. It wasn't only pointers but a lot of other concepts became clear to me.
Thats why when I start teaching someone programming, I start by drawing up a very basic scheme of a microprocessor working with a ram chip and explain how it addresses, reads and writes data from the ram in order to explain to them what exactly their code does in the background on the lowest level. Those who are able to get it immediately will have a much easier time learning peogramming and especially pointers.
Isn't it interesting how the human brain works?
I've had similar experiences, yet different in some ways.
For me, when I get stuck on something, I've learned to just walk away from it for a while, because always, I have a dream while asleep where whatever thing I'm confused on or didn't quite get, becomes clear.
It reminds me of decades ago. I was writing a small-business app for a mom and pop shop.
I forget what it was now, but back then, I got stuck on what some code should be and its math.
I was literally stumped at that moment.
I went to bed one night, leaving the computer running in the other room.
As I slept, I was dreaming about my code. It was weird, because in the dream, the code was scrolling up and down, blurring the lines of code. Sort of like a spinning cylinder. Up and down, repeat.
As it would spin up and down (lines moving up then down then up again) the scrolling was slowing down.
When it slowed down, it stopped right at a line of code. You guessed it, IT WAS THE CODE THAT I COULDN'T WRAP MY HEAD AROUND!!
I woke up right then, ran to the computer, found the position in code where that line of code should be, typed it in and YUP! IT WORKED!
Since then, I've had many similar experiences where something that I found difficult to grasp, the answer was a nap away. LOL
The brain is so interesting.
@BlondieSL Definitely, giving your brain a rest is the best thing you can do in order to learn or solve something that you just cant grasp.
I work at a startup, and we get some interns from time to time. After the first couple of interns, I realized that there is one technology with which they all struggle and lose motivation - redux. Redux is quite complex to conceptually grasp, but it is really easy once you see the full picture.
I had this one intern that just got stuck on it and wasn't moving an inch forward. I tried explaining everything twice, three times, asked him to watch me code, asked him to go over the documentation, and he just wasn't getting it. He went on a break for a week - a summer vacation. He came back to the office a week later, and I decided to start him off easy - a simple React todo application to warm up. He had it done in a few hours, and then I asked him to try and implement redux logic on the application. I was expecting him to get stuck and ask for help. I was shocked when about an hour later he said "done". I asked him if he was on a vacation or if he was at home studying. He said to me that the night before, before going to bed, he was dwelling on Redux, thinking about it constantly - he was visualizing the data flow, imagining the inner workings and what goes on behind all the function calls and suddenly he just grasped it. He doesn't know how it happened. He just said that he managed to connect the dots without having any code in front of him.
Since then, whenever I am solving something difficult, I give it time. From time to time, I will try to visualize everything, write my ideas in notes, and after a week of this, I review all my notes and see if I have an idea or a solution. This works for me 9/10 times.
Free the mallocs!
Awesome video. Pointers are always misunderstood and often not done properly, they get especially finicky when you start using classes and C++ conventions, like the Trilogy of Evil (Copy, Assignment, Destructor operators) where data inside pointers has to be handled, not just the pointers themselves. One thing I came across was that in classes, you can allocate memory space with malloc, but it will not call the constructor for you. Another thing I've come across a lot when debugging is that people will call delete on the pointer when it's freed, but you also have to set the pointer to null in order to not leak that last bit of memory.
One thing that needs to be taught is how to clean up after your allocations (free() and delete/delete[]). I never learned this from three separate classes, until I went for a Game Development degree at Full Sail.
I love function pointers. I thought that was the coolest shit when I was studying CS in college.
Yeah, took me about a year before I could write somewhat complex (and working) code using pointers. Back then it took repeated reading of K&R and tests to get my head around pointers.
The Commodore 64 screen background colour byte example was brilliant!
We who are about to design and build salute you!
Man, I could have used such a good explanation 30 years ago!!
Thank you Dave!
What helped me grasp them was putting the asterisk next to the type, and mentally thinking of a byte or char pointer as its own type. So instead of reading "byte star pBkgndColor", I read byte-pointer-type pBkgndColor.
byte* pBkgndColor;
Silly, I know, but it helped make things click for me. In my mind having the asterisk next to the type makes much more intuitive sense.
For those of you like me where you started out with a scripting or higher level language and then decide to take on something like C/C++, it can feel scary like learning how to drive stick shift after you're used to driving an automatic. Everything is fine at first until you encounter pointers or the compiler starts yelling at you, sort of like how you're cruising along stick in shift but then start stalling out going up a steep hill or a railroad crossing. It will get better and two good advantages you guys have today that I didn't have in the past is online C compilers and Virtual Machines. It's a good way to practice all these concepts while still in a safe sandbox environment. 😎
Minor note. The examples used C++ std library features (eg cout), so technically you were using C++, not C. However since the discussion was about pointers that issue is sort of a minor trivia item.
I thought the same. Why make a video (good as it was otherwise) about C pointers and then use C++ features, when in C++ your "house" struct would have been a class?
It's difficult to fault someone with this background and skills, but it did seem strange to me too.
Primary reason is that I wanted publicly accessible member vars for each access in the examples and structs are natively public whereas classes are private by default. And I wanted my pointer examples to be raw C even if the I/O scaffolding around them used C++
@@DavesGarage
Sure. I understand your *logic.
Just thought I’d note it for any C newbies viewing this that might be confused by the C++ features.
@@frubert123 everything in the video applies to C as well, just instead substitute printf for std::cout. Same goes in the opposite direction, just instead substitute typedef struct for a class with public member variables. Sure, they used C++ for the examples, but everything talked about is just the same for C, so it doesn't really matter.
@@frubert123It's very common to mix the two languages. I often do it. I work on legacy code that is mostly a mix of C and C++. I'm pragmatic. I do what works and code in whatever the existing style is and ignore the language lawyers.
Even though I come from TTL and then Assembly, I’ve always had inordinate amounts of trouble with symbology involving assembler-directives, figuring out other peoples UIs and pointer notation. 😢
Maybe I’ve been living on the ‘Spectrum’ all along 😂
Thanks for the video and clearing up some of the confusion with the notation! 😊
This is really, really helpful. You have a talent for explaining things.
Almost forgot what pointers are ... been writing code in Java, C#, JS, Python for 20 years... Thanks for the refresher! The power pointers give is very much under-estimated.
I recently started teaching the introduction system's programming course at my university, and this should make for a great review resource going forward, thank you for this and the many great videos!
Best thing ever is function points, and pointers to arrays of pointers.. It makes huge stacks of case or if else conditions moot.. just makes an array that matches your data, and then stick it full of function pointers.. Instead of a lot of complex if/else or case statements.. it's just dereferencing the pointer and jump.. :)
Pointers are one of those things that isn't complicated but sounds complicated because hard to explain
THIS. this is the video that FINALLY made it click for me. thank you Dave
Before I learned C I worked with assembler. As you can imagine I never understood how anyone may have problems with pointers. 😂 It is soooo natural! 😅 Pointer to pointer? Non issue... 😂
Your history with C is almost exactly the same as mine. Love C
Wow! Dave, I hope to get your permission to use that video to introduce pointers to a lot of people, or to introduce a lot of people to the pointers ;-) Its painfully necessary these days!
The first rule of pointers (in any language that has them) is to design your code to minimize the need for pointers.
Also, declare each variable on a separate line.