Hi Mike, i'm from Brazil and in my 7 years as a software developer, studying by different resources (courses, documentations, books...) you and your channel are the best resource to study that i found. Thank you!
Hi bro! You are really good at teaching, I´ve seen some videos related to memory in C and thanks to yours I finally got it! I will continue learning with your videos!
Very neatly explained. Yes, Stackoverflow is second fav now after this channel :). I'm loving C lang watching your videos. It's great to understand and see things from system admins perspective. Thank You.
Great video. I learned C++ first, now backfilling concept gaps with C. Your C and C++ have videos have been critical in my development. I will continue to promote you but let me know of additional ways I can support you. Also, I see you are also doing videos on D. I’m not familiar with that language. Is that the next logical evolution from c or c++?
Cheers, thanks for the kind words! Feel free to share as you like! D is indeed the next evolution in the C-family of languages. I've found it allows me to think in different paradigms (specifically functionally, concurrent programming, and generic programming) more efficiently. Neat thing about D is it also has a C compiler built-in, so all the knowledge you otherwise learn here applies :)
Hi Mike and thanks for your precious job. I’m learning a lot from your lessons with a clarity I haven’t found anywhere else. I appreciate it very much. A question: why don’t you do in-depth courses on other platforms like Udemy or on your site?
Hey Mike, Just a typo in your drawing at 2:57. You mentioned storage space for type integer is 4 bytes, but you drew a box of 5 bytes. It is a pretty obvious typo, but could confuse some new learners. I am trying to get from intermediate to expert at C, and find your videos very useful. By the way, does integer type always require 4 bytes of storage, or is it compiler dependent?. Do some compilers allocate 8 bytes to store an integer? Thanks!
Good catch! Generally speaking, it is compiler dependent on the size of the 'int' type. There exist 'fixed-width types' that may be better for portability that otherwise are consistent -- you can learn about them here :) ruclips.net/video/XR6ofUpjfB4/видео.html
To us as the programmer, it is contiguous. In reality, a 'physical address' could be scattered, but our operating system will make it appear as if the addresses are contiguous.
Indeed could be a problem for space. That said, the memory returned even on embedded from malloc will always be contiguous or otherwise return null(if memory cannot be allocated). @@rudolfbouzek6944
Hey thanks a lot for a great series! It would be cool to see video about memory arenas style if programming in c, and how you can basically create stacks for yourself dynamically, or at least its how I understood it)
Hey Mike, thank you for the lesson. It was a good call to *printf* the stack and heap addresses inside and outside of the scope of the *allocateOnHeap* Sorry for a silly question but what happens if we don't *free(heapData)* in our main function? Does it mean the memory stays allocated until we reboot our system? Or the effect is less drastic and the memory stays allocated until our program is closed?
The operating system will eventually reclaim the memory once the process terminates. So where this truly becomes a problem is if you have long running programs (e.g. a web browser, a server, a game), that is slowly (or quickly) leaking memory over time. :)
Hi, good material, Thank You. I have also question about free() function. How free knows how many bytes should be released ? It is only a pointer to the first element of block, it does not contain any information about block size.
@@specialx9856 Ah, so in this example I'm demonstrating that heap allocated memory (the chunk of memory from malloc) is stored in the address of a pointer. The point is that we need to have a valid pointer to that same address (whether in the function, or in another pointer which is what is returned from the function -- effectively another copy of the original pointer that pointed to a chunk of memory). So as long as we are free'ing a chunk of memory once, we can do it within the function or outside. Generally speaking, we do have to think carefully about how we manage our memory.
So what about global variables? Are they just stack allocated and cleared when the process ends? Instead of being cleared when leaving a specific scope I mean.
13:57 I glitched for a sec here. I was like what is going on? How can we use the function *bar()* before declaring it? But since our program actually starts with the main() function, everything's fine.
![Pointers in C / C++ [Full Course]](/img/1.gif)
Hi Mike, i'm from Brazil and in my 7 years as a software developer, studying by different resources (courses, documentations, books...) you and your channel are the best resource to study that i found. Thank you!
Cheers, thank you for the kind words!
This is a really high quality series. Thank you Mike.
You're most welcome!
Hi bro! You are really good at teaching, I´ve seen some videos related to memory in C and thanks to yours I finally got it! I will continue learning with your videos!
Thank you for the kind words! Enjoy the series!
thank you so much bro, this is gold
Cheers, glad that this was helpful!
Very neatly explained. Yes, Stackoverflow is second fav now after this channel :). I'm loving C lang watching your videos. It's great to understand and see things from system admins perspective. Thank You.
Thank you for the kind words! :)
Great video. I learned C++ first, now backfilling concept gaps with C. Your C and C++ have videos have been critical in my development. I will continue to promote you but let me know of additional ways I can support you. Also, I see you are also doing videos on D. I’m not familiar with that language. Is that the next logical evolution from c or c++?
Cheers, thanks for the kind words! Feel free to share as you like! D is indeed the next evolution in the C-family of languages. I've found it allows me to think in different paradigms (specifically functionally, concurrent programming, and generic programming) more efficiently. Neat thing about D is it also has a C compiler built-in, so all the knowledge you otherwise learn here applies :)
Hi Mike and thanks for your precious job. I’m learning a lot from your lessons with a clarity I haven’t found anywhere else. I appreciate it very much. A question: why don’t you do in-depth courses on other platforms like Udemy or on your site?
Thank you for the kind words! I will add more courses on courses.mshah.io over time 🙂
This Video is great.
I feel a lot of accumulated information which I've got over years are organizing in my brain in the most clear way .
Thanks a lot
Cheers!
Hey Mike, Just a typo in your drawing at 2:57. You mentioned storage space for type integer is 4 bytes, but you drew a box of 5 bytes. It is a pretty obvious typo, but could confuse some new learners.
I am trying to get from intermediate to expert at C, and find your videos very useful.
By the way, does integer type always require 4 bytes of storage, or is it compiler dependent?. Do some compilers allocate 8 bytes to store an integer? Thanks!
Good catch! Generally speaking, it is compiler dependent on the size of the 'int' type. There exist 'fixed-width types' that may be better for portability that otherwise are consistent -- you can learn about them here :) ruclips.net/video/XR6ofUpjfB4/видео.html
great video Mike😍
Question: When I use "malloc", will the data be contiguous in memory or scattered around wherever there is space available?
To us as the programmer, it is contiguous. In reality, a 'physical address' could be scattered, but our operating system will make it appear as if the addresses are contiguous.
@@MikeShah Thank you, so on microcontrollers where there is no OS, this could be a problem (fragmentation and inability to find space).
Indeed could be a problem for space. That said, the memory returned even on embedded from malloc will always be contiguous or otherwise return null(if memory cannot be allocated). @@rudolfbouzek6944
Hey thanks a lot for a great series! It would be cool to see video about memory arenas style if programming in c, and how you can basically create stacks for yourself dynamically, or at least its how I understood it)
Cheers! That's a nice idea -- I have some materials on this for C++, so I can consider a video like this in the future
Life saver! Tysm 😍
You are most welcome!
I think well understanding of pointers and memory allocation is crucial ( Key ) to be good at Data structures ?
Correct, at least in C!
Hey Mike, thank you for the lesson.
It was a good call to *printf* the stack and heap addresses inside and outside of the scope of the *allocateOnHeap*
Sorry for a silly question but what happens if we don't *free(heapData)* in our main function?
Does it mean the memory stays allocated until we reboot our system?
Or the effect is less drastic and the memory stays allocated until our program is closed?
The operating system will eventually reclaim the memory once the process terminates. So where this truly becomes a problem is if you have long running programs (e.g. a web browser, a server, a game), that is slowly (or quickly) leaking memory over time. :)
@@MikeShah Thank you for clarifying!
stack overflow ( our favorite website 🤣🤣🤣🤣 )
😁
Hi,
good material, Thank You.
I have also question about free() function. How free knows how many bytes should be released ? It is only a pointer to the first element of block, it does not contain any information about block size.
It's actually allocating a few more bytes in a header block to keep track of this :)
Thanks for the video, very helpful, but why we don't use free() inside the function? Is it because we can't return the pointer of array.
Cheers! Can you provide a timestamp?
25:17@@MikeShah
int* allocateOnHeap(int x){
int* array = (int*)malloc(sizeof(int) * 50000);
free(array); // Like this
return array;
}@@MikeShah
@@specialx9856 Ah, so in this example I'm demonstrating that heap allocated memory (the chunk of memory from malloc) is stored in the address of a pointer. The point is that we need to have a valid pointer to that same address (whether in the function, or in another pointer which is what is returned from the function -- effectively another copy of the original pointer that pointed to a chunk of memory). So as long as we are free'ing a chunk of memory once, we can do it within the function or outside. Generally speaking, we do have to think carefully about how we manage our memory.
Thanks, now I understand. @@MikeShah
So what about global variables? Are they just stack allocated and cleared when the process ends? Instead of being cleared when leaving a specific scope I mean.
global variables are baked into the binary file (i.e. object file or 'executable object file' that you double-click). They're always present.
@@MikeShah ah, so when the process is run they are stored with the source code?
@@Rocketmang Stored in the executable, so the address is loaded when the program starts, correct.
@@MikeShah Ah ok. Cool! Thanks for clearing that up for me! Loving this series so far!
@@RocketmangCheers!
13:57 I glitched for a sec here. I was like what is going on?
How can we use the function *bar()* before declaring it?
But since our program actually starts with the main() function, everything's fine.
It appears the compiler was smart enough to figure this out, but I probably should at least provide the declaration of bar() before foo().
13:31 You bet!
Hehe :)