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.
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.
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
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. :)
Indeed from the descendant of barbarians who invaded an dgenoicded people to take their lands its impressive. Im sure though that those of concience and humanity could explain it much better. And in much less time.
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.
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.
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
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.
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.
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)
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!
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
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
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,
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.
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.
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. 😎👍
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.
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.
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".
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.
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! ❤
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.
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!
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.
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.
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.
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.
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!
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!
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 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.
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?
Thank you so much for putting together such a great video on pointers. I’ve watched it twice and I plan to watch it three or four more times until I understand every single concept of gone over here. The function pointers are still a mystery to me how I would use those affectively
Thank you so much sir for this, it means a lot for a beginner like me 🙏. I am a Java/Kotlin programmer, (I know c/c++ but only the basics) I have wanted to master C++ for a long time, and now I think I can😅, Thanks again 🙏 ❤ From India 🇮🇳
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.
There's an audio book coming? Wow! Can't wait! Have the physical book and love it so far, but finding time and mood for sitting down to read on paper is hard.
13:08 Question: Why does compare expect two "const void*" instead of "void*"? What's the difference? Why is const necessary or important in this scenario?
Because the mere act of comparing two elements should not change them! The subsequent cast to int-pointer is bad, by the way. It should be const-int-pointer.
@@fredoverflow Right, but I still don't understand the difference. Does the compiler treat these variables different? I mean, I can compare two variables without changing them anyway without declaring them as const. I would have assumed a deeper and more sophisticated reason.
@@Zeitgeistpionier const protects the programmer from his own stupid mistakes. Given int-pointer variables x and y, the following mistake compiles, but does the wrong thing: if (*x = *y) ... With const-int-pointer variables, the compiler complains about assignment to const. Right, we don't want assignment, we want comparison: if (*x == *y) ...
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.
Once way to verbalize the asterisk and ampersand when dealing with pointers is to read "at address" for the asterisk and "the address of" for the ampersand. So "int *pSomeHouse" reads as "integer at address pSomeHouse" and "pHouse = &someHouse" reads as "pHouse is the address of someHouse". This may not work for advanced constructions like function pointers, but when just starting out in C/C++ it may help when getting more comfortable with the basics of pointers.
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.
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).
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.
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 got my first taste of this type of pointer use (outside of assembly language) when I had to learn Modula-2. Thankfully it was a realtively small leap from there to using them effectively in C but the pointer declaration and use nomenclature in C was a bit confusing. This was very helpful thanks.
Thanks for your content, i enjoyed a bunch of your videos. Code at 9:10 is actually C++ and would not compile because of the pointer declaration with the literal string.
![แฉกลโกงงานวัด 2024 [ โกงมั้ยครับ ep.106 ] | DOM](http://i.ytimg.com/vi/taC5dpP3HXA/mqdefault.jpg)
Yea this guys been coding in C longer than I’ve been alive. I’m going with this guy.
hes also been scamming people with fake promises to speed up their pc with programs for money than youve been alive
@@doug_buck ah shit. any other recs?
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)
@@DrMerlin62👏
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!
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.
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
at this point I'm convinced no programmer on earth knows how to teach. just my own salt on the issue but I think it's somewhat valid
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. :)
Indeed from the descendant of barbarians who invaded an dgenoicded people to take their lands its impressive. Im sure though that those of concience and humanity could explain it much better. And in much less time.
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.
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?
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
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.
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.
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)
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!
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
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
Starting with C and fiddling with memory made understanding how more higher level language handle memory / what is passed by reference vs value.
[C]lear and straight to the point(er). 🎯
I first toyed with C a year ago and was so confused by pointers. Learned a lot here!
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,
Wow. This made a whole lot more sense to me by the end. Thanks Dave!
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.
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.
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. 😎👍
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.
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.
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!!!
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".
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.
Thanks for the pointers, Dave!
Thank you. The house analogy really helps me grasp what pointers are and what they are used for exactly. Makes it easier to understand lol
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! ❤
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.
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....
This video is exactly what I was looking for to help me improve my programming skills. Thank you for making it!⭐♥
12:30 : in modern C/C++ you don't need the (* part to call a function pointer. You can just do this:
int sum = pAdd(5, 3);
Very clear introduction to the most important things about pointers.
Remember struggling a lot with those when I started using C++.
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"!
Let me speak from my heart =) This description was absolutely incredible! I wish I've had it about 5 years ago..
nothing short of amazing. I literally know nothing about C lang, but understood some of what he said
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.
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.
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.
This is really, really helpful. You have a talent for explaining things.
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!
I hit "thumbs up" on the video for the thumbnail alone, lol.
BYOB - Bring Your Own Bytes?
Such a good video Dave, straight to the point. much love from Argentina!
Thank you Dave,
Your void pointer section helped me make sense of code that looked like this:
*((A *) B) = C
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.
Once the light bulb went on in my head, it was mind-blowing. I was obsessed with it for months afterward.
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.
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.
Picked up writing some code for microcontrollers, my C is a bit rusty so these video's are very welcome.
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!
Thanks Dave!! I am learning C++ and pointers where the most challenging part. This was a great help.
Man, I could have used such a good explanation 30 years ago!!
Thank you Dave!
THIS. this is the video that FINALLY made it click for me. thank you Dave
Excellent! My best saga was creating a pointer to an array of functions (oh what fun) 😆
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
one of the best videos on this topic in my opinion. thank you!
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!
Great video. Straight to the point, easy to follow along.
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 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.
Awesome !! I now understand pointers better than I ever had. Thanks
@12:30 The brackets and * are not required when calling the function pointer. You can just call sum = pAdd(5,3)
I'll try it! Good catch!
That's a very nice refresher on pointers. Thank you!
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.
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?
The Commodore 64 screen background colour byte example was brilliant!
Thank you so much for putting together such a great video on pointers. I’ve watched it twice and I plan to watch it three or four more times until I understand every single concept of gone over here. The function pointers are still a mystery to me how I would use those affectively
I love function pointers. I thought that was the coolest shit when I was studying CS in college.
I've been waiting for you to dive into programming like this... Did not disappoint. Bravo 👏👏👏👏
thank you Dave explained very well in 14 minutes would you consider doing a deep dive in function pointers? the syntax can be super confusing
Thank you so much sir for this, it means a lot for a beginner like me 🙏. I am a Java/Kotlin programmer, (I know c/c++ but only the basics) I have wanted to master C++ for a long time, and now I think I can😅,
Thanks again 🙏
❤ From India 🇮🇳
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.
There's an audio book coming? Wow! Can't wait! Have the physical book and love it so far, but finding time and mood for sitting down to read on paper is hard.
Thanks for this, Dave. I led the way you explained and the examples. I hope this C/C++ videos keep coming :)
Very helpful video, thank you!
13:08 Question: Why does compare expect two "const void*" instead of "void*"? What's the difference? Why is const necessary or important in this scenario?
And why does qsort get sizeof(int) instead of sizeof(*numbers)?
Because the mere act of comparing two elements should not change them!
The subsequent cast to int-pointer is bad, by the way. It should be const-int-pointer.
@@fredoverflow Right, but I still don't understand the difference. Does the compiler treat these variables different? I mean, I can compare two variables without changing them anyway without declaring them as const. I would have assumed a deeper and more sophisticated reason.
@@Zeitgeistpionier const protects the programmer from his own stupid mistakes. Given int-pointer variables x and y, the following mistake compiles, but does the wrong thing:
if (*x = *y) ...
With const-int-pointer variables, the compiler complains about assignment to const. Right, we don't want assignment, we want comparison:
if (*x == *y) ...
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.
Feels like a PBS documentary. love it.
Who could teach you better than a gentleman made his hair white on programming? Absolutely no body 🙏🙌
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.
Once way to verbalize the asterisk and ampersand when dealing with pointers is to read "at address" for the asterisk and "the address of" for the ampersand.
So "int *pSomeHouse" reads as "integer at address pSomeHouse" and "pHouse = &someHouse" reads as "pHouse is the address of someHouse".
This may not work for advanced constructions like function pointers, but when just starting out in C/C++ it may help when getting more comfortable with the basics of pointers.
We who are about to design and build salute you!
:P Man I feel so smart for once, after 23 years of hobbyist programming in C/C++ I knew all these tips!
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! :-)
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).
Im a newbie, but Byref and Byval explained at 5:50 really dumbed it down to help me understand.
very good explanation. especially the function pointer part.
Master Pointers! I've been waiting for him!
I made the jump to C from Assembly, somewhere in the eighties.
Pointers are trivially easy to understand if you know assembly.
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 :-)
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 got my first taste of this type of pointer use (outside of assembly language) when I had to learn Modula-2. Thankfully it was a realtively small leap from there to using them effectively in C but the pointer declaration and use nomenclature in C was a bit confusing. This was very helpful thanks.
Always preferred to use & references whenever possible in my C++ days - like void (House& house) { cout
Thanks for your content, i enjoyed a bunch of your videos. Code at 9:10 is actually C++ and would not compile because of the pointer declaration with the literal string.