No; not always. Sequences of bits are not equivalent to integers, the same way phone numbers are not integers, but sequences of (usually) decimal digits: try to remove leading zeros in some of them without breaking them, or get a valid phone number by multiplying two other phone numbers. Whether 32 bits are an integer, a float, a block of 32 single-bit flags, a 4 ASCII character array, or for example a complex number of two short unsigned integers, all of this is derived from a high-level abstraction data type that permits certain instructions and values. A variable is a named storage of a certain data type (and thus size), interpreted as an integer, or otherwise.
@@swavek_wlodkowski i think you missed the point of his comment. OP was making the joke that variables are not real numbers (as in the set of real numbers) but rather they are integers (as in the set of integers) because that is how we generally interpret their physical configuration in memory -- through abstraction as you pointed out. At least I think that's what op meant lol
Overview: Declared variables often exist close to each other in memory space, which can make certain bugs hard to track down, especially if you're writing to out-of-bounds indices in a stack array because that can overwrite the other local variables that are declared.
The bugs that result from these are very confusing indeed! Once spent an entire night trying to track down why one array was being overwritten Turns out an adjacent array in memory was being written to out of bounds.... Thankful for GDB!
Really enjoy watching your videos. I'm a c/c++ developer, but never really had the pleasure of taking a lot of cs courses -- I can only really think of 3 or 4. Your simplified, bite-sized, demos and explanations, are fantastic.
Great explanation. To add to this discussion, a variable does not even have to reside in addressable memory. A variable is just an abstraction of a named storage location. That's it. A compiler may put it in some location in primary memory, or inside a CPU register, if possible. The latter case is important to understand why some multi-threaded code behaves the way it does. Lastly, let's not forget about variables declared as references (C++), which sometimes can be handled under the hood as pointers, but often do not have to be mapped to any additional storage location of their own at all. // Thanks for the video!
I would add that in a language like C++, a variable is an abstraction that associates a location in memory, a type, and a name in a given scope. The data in the memory is just a bunch of bits; it's the type of the variable that determines how that data is interpreted and manipulated, that conveys meaning to those bits. This is a fundamental difference with dynamic languages where the type is part of the value itself, not the variable, so thinking about variables as boxes for values tends to be less of an issue.
some things I wanna add: - using the address (e.g. to print it) might be what's responsible for spilling on the stack in the first place and the idea of a memory blob is not really useful for values that are only in registers - 7:30 the compiler is technically allowed to call `atoi(argv[1])` and assume it returns 0 and consequently initialize d to `{42}` from the get-go
the compiler can decide pretty much the entire memory layout if you want to, but usually it doesn't because PIE allows the kernel to randomize addresses for security reasons. if you compile the following: '#include int main() { printf("main: %p ",(void*)main); return 0; }' with the -no-pie flag (for gcc) it will always output the same address. of course that address is picked by the linker, but thats part of the compiler in my opinion. (and you can of course write a linker script to tell the linker exactly where you want your code, if thats important to you. but the kernel might not like some address you are trying to get if its reserved for kernel use) anyway, i think that what the video referred to is that the compiler decides the layout of variables on the stack, not the absolute address of the variables, just their relative offset to each other. same for statically allocated variables, the compiler decides their relative order and padding and all that on the .data or .bss or .rodata sections
This issue is why I disagree with them no longer teaching ASM as the first language. When I went started college they expected you to take ASM before you could take C. I've never known a programmer who came from that system that had issues with understanding these and other more complex issues. Sure there were lots of people that dropped because they couldn't handle ASM. I honestly think the programming world is better for that.
That sorta sounds like a buffer overflow attack. Say you have an input field, the attacker essentially write enough data into that field that it reaches the code section of memory. This can be used to run some code
@@case_sensitive depends on where the buffer is located. If the executable buffer is in the heap theres no guarantee that the input can overflow into said buffer. Especially not when the input is on the stack
Until you choose some tail-recursion examples where it actually can be. If you start thinking about variables as anything more than an abstraction of storage (to be resolved by a compiler) with a specific life cycle, there is likely to be some edge case where your simplification no longer holds true.
you know what is even worse to debug? giving a value to a pointer to function (The address of a function)-> check if that value is NULL. you find it NULL THOUGH you gave it a value which is a function name. but if you give a value to a that pointer which is the address function -> call the function once using the pointer -> check if that value is NULL -> now it's not NULL. why? I DON'T KNOW. and this makes me crazy.
Variables don't have to exist in memory at all. If the compiler can use a CPU register all the way to represent a variable, it will do so and no memory is ever assigned to that variable. Of course, this will only wok if you never use `&a` to get the address, as a register has no address and that way you force the compiler to assign memory to that variable. A compiler may even assign neither memory nor a register to a variable if it doesn't have to. E.g. consider this code `int a = getA(); useA(a);` The compiler can turn that into `useA(getA());` and thus won't manifest the variable at all by just passing through the result of one fiction call to another one, and how that works is platform specific; it might use memory or registers or neither. Even if it uses register/memory, that isn't assigned to a variable, just use a temporary storage. Also if two variables never overlap in usage scope, the compiler may use the same memory for both of them to save memory. E.g. "int a = ...; /* 1st code that uses a */ int b = ...; /* 2nd code that uses b but never a */` If there is no way to get from the second code back to the first one, why shouldn't a and b share the same memory? However, most of that will only happen if you build with optimization enabled as a compiler must perform some analysis to know which variable scopes do overlap, which variables can be passed through directly, and which variables won't ever require memory and can just be a register.
const variable is just a syntactic sugar by the compiler to prevent the programmer from changing that variable before doing compilation, where in real life nothing is "const" the const variable can change if you change the location of memory it holds, the same goes for private members of a class and everything else, everything is changeable if you reach their memory address
Great video! Also, variables are just zeros and ones, if we all agreed on a new arbitrary way of representing numbers in binary, the same variables that seem so clear today would become nonsense. We know 0001 == 1 because we all agree on it. That's the importance of standards
nice video, maybe we can regard all variable as a pointer that point to some places in memory. then we must know which places we want it to points to and make true it do not point to the places we don't want it to point to
I think it is counter-intuitive to not refer the black board as a "stack". Also it would've been useful to expand on the idea by explaining objects and the heap, because a variable always points to memory on the stack, but the value on the stack contains all information to find the object on the heap, like address and size.
Not true. The story holds also for global variables. They are not on the stack. Besides that, the compiler can store variables into CPU registers in stead of memory.
Gonna be honest this one disappointed me a little, not cause the video was bad! But because I was expecting it to be about how the compiler waits to actually initialize variables until they’re used. Like if you debug a program, have a bunch of variables assigned, then do a few lines of arithmetic, break on the first like of that, then any variables not used on that line just dont exist to the debugger… sometimes at least. Reasonable behavior but a little annoying sometimes. Was hoping to learn more about it
Hi Jacob! I really would appreciate an answer on this. I am just curious why is it you make all this C/C++ content? Seems like C isn't that popular nowadays to talk about and you have kind of made it your thing. Don't get me wrong, I love your content and I personally find C to be my favorite programming language.
This is the main problem with people looking at languages like C from a low level point of view. Variables are real in C, your use of pointer arithmetic is undefined, C doesn't target your machine but an abstract machine, C is not assembly and there's no 1:1 mapping between the two. Just because your variables might be optimized away or anything else, it doesn't relate to C at all.
Oh nooo, my favorite informative technologies teacher, Jacob-san, became insane! What should I do, after all this, I can’t accept the loss of daddy senpai from my life. Is the world be kind to get him up and mentally healthy after every war with pointers we got through together. /ᐠﹷ ‸ ﹷ ᐟ\ﾉ
Not helpful, there is no functional distinction between the different analogies you used. What you're saying only makes any sense because I already know what you're trying to say for how it works. I'm honestly still confused about what the problem is with thinking of them as "real" is. I guess I don't get what you mean by 'real' since it all would work identically with the bucket analogy... we start at bucket A and move over one bucket... I think the conceptual thing isn't about 'realness' but about layout and indexing. Don't click your heels, go use sanitizers like Asan, Tsan and Ubsan, and memory analyzers like memstomp and Valgrind. And don't forget regular compiler warnings, get that -pedantic, etc.... And when things are good, we can see if we can make them bad with fuzzers.
Well, processes aren't real either. can we have a video about how the actual unit of work in linux is a task, rather than process? then we could get our hands dirty with the clone() syscall. like, how only fd and/or address space is shared etc. how fork is basically a subset of clone. i'd really love that.
Not really; I would not say so. Not just the stack (also CPU registers or static segments), and not the heap (because the heap offers dynamic storage duration, and variables do not use it). They are also not references (which are a high-level concept), but I suspect that you meant that they can be translated to a memory address under the hood - this is also not universally true (it does not apply to register storage variables).
@@swavek_wlodkowski I know, just wanted to underline the fact that variables reside somewhere. And variables in (some)interpreted languages (JavaScript) are on the heap.
@@georgecop9538 This could be right, if not for the fact that the video starts with C/C++ in the thumbnail and the author wears a malloc t-shirt. Then someone would argue that there is a environment where what a programmer sees as a variable is stored in a secondary memory of some remote network host ("databases, I am looking at you!").
@@georgecop9538 Not always, variables may in fact reside nowhere. Create a variable, don't use it, compile with -O3, start GDB and look for your variable, good luck.
TL;DR C is not an assembly. It's high-level language that abuses memory concept and allows a lot of optimizations thanks to undefined behaviours (delete code that can't be real if you read it as it written, not as you'll think it will run on CPU).
This. The whole "*ackshually* x is really just y" tends to be false in 99.9% of cases, and are often just misconceptions because people believe that there's a 1:1 mapping between assembly and C. Just because x can become y when compiled, doesn't really say anything about x or y.
Honestly I feel like this title is clickbait I already known all u tried to explain here and I still think they are "real". U could use this type of logic to littelary anything. What u see with your eyes is not real! It's just separate waves that your brain process and I can demonstrate that by using glasses. U see, image is different so it's not real! U can still use bucket analogy to explain this. "buckets have different sizes and if u try to add to many water to them they will overflow to next bucket". U littelary removed buckets to add squares that were doing exactly the same thing as bucket. And pointer is just pointing to the bottom of bucket.. Video itself is as always very good, but this metaphor about lack of existence feels silly, silly enough to make it feel like clickbait
This is a great video, unfortunately with a terrible title. I suspect it's for clicks, but bounds checking is such a critical concept. I wish you had named this something different. Just honest feedback, otherwise great work man.
Also good way to protect yourself from buffer overruns is to forgot abot dynamic arrays concept. They aren't real. If you really want them, just implement for yourself arenas using realloc and _write_ your code as operations on memory, not in OOP terms. OOP is generally bad idea, you just spending your time to it instead of writing code that does something (like a tool for specific job) and name your functions and types (structs, unions, complex stuff) like folder names, from top to bottom.
No. Your variables are 'real' fsvo 'real'. Buckets is a perfectly good analogy. Everbody understands that buckets come in different forms and different sizes with different capacities. What you're trying to demonstrate is that your buckets are somewhat fragile and that the integrity of your buckets can be compromised if you get your code wrong. Well that is perfectly true, and a valuable lesson, but I don't see how making out that variables are not 'real' is helpful to a beginner... and you don't define 'real' in any meaningful way anyhow. And your title is annoying clickbait.
Yes, they are not real, they are integers.
No; not always. Sequences of bits are not equivalent to integers, the same way phone numbers are not integers, but sequences of (usually) decimal digits: try to remove leading zeros in some of them without breaking them, or get a valid phone number by multiplying two other phone numbers. Whether 32 bits are an integer, a float, a block of 32 single-bit flags, a 4 ASCII character array, or for example a complex number of two short unsigned integers, all of this is derived from a high-level abstraction data type that permits certain instructions and values. A variable is a named storage of a certain data type (and thus size), interpreted as an integer, or otherwise.
@@swavek_wlodkowski i think you missed the point of his comment. OP was making the joke that variables are not real numbers (as in the set of real numbers) but rather they are integers (as in the set of integers) because that is how we generally interpret their physical configuration in memory -- through abstraction as you pointed out. At least I think that's what op meant lol
All integers are real, but i get that you are referring to the real numbers that are nut integer.
Integers are a subset of real numbers :)
In Fortran, GOD is REAL (unless declared INTEGER).
Variables aren't real, they can't hurt you.
Variables: Segmentation fault
It's a lot of fun when you do that against mapped hardware controller memory.
Understanding what's going on under the hood is important.
Overview: Declared variables often exist close to each other in memory space, which can make certain bugs hard to track down, especially if you're writing to out-of-bounds indices in a stack array because that can overwrite the other local variables that are declared.
... well never had this bugs in Rust 😎
The bugs that result from these are very confusing indeed! Once spent an entire night trying to track down why one array was being overwritten
Turns out an adjacent array in memory was being written to out of bounds....
Thankful for GDB!
@@voidwalker7774Any sane C++ developer would avoid doing this mistake too.
Really enjoy watching your videos. I'm a c/c++ developer, but never really had the pleasure of taking a lot of cs courses -- I can only really think of 3 or 4. Your simplified, bite-sized, demos and explanations, are fantastic.
Great explanation. To add to this discussion, a variable does not even have to reside in addressable memory. A variable is just an abstraction of a named storage location. That's it. A compiler may put it in some location in primary memory, or inside a CPU register, if possible. The latter case is important to understand why some multi-threaded code behaves the way it does. Lastly, let's not forget about variables declared as references (C++), which sometimes can be handled under the hood as pointers, but often do not have to be mapped to any additional storage location of their own at all. // Thanks for the video!
This is tricky
Even regular non-reference variables can be totally optimized away by the compiler on the more aggressive optimization settings.
I would add that in a language like C++, a variable is an abstraction that associates a location in memory, a type, and a name in a given scope. The data in the memory is just a bunch of bits; it's the type of the variable that determines how that data is interpreted and manipulated, that conveys meaning to those bits.
This is a fundamental difference with dynamic languages where the type is part of the value itself, not the variable, so thinking about variables as boxes for values tends to be less of an issue.
Therapist: "... is that 'pointer to the variable' in the room with us now?"
Me: ... *shudder*
some things I wanna add:
- using the address (e.g. to print it) might be what's responsible for spilling on the stack in the first place and the idea of a memory blob is not really useful for values that are only in registers
- 7:30 the compiler is technically allowed to call `atoi(argv[1])` and assume it returns 0 and consequently initialize d to `{42}` from the get-go
"Size doesn't really matter here" what a chad 🗿
Sounds to me like ‘C’ stands for ‘clobber memory’, lol.
Thanks for all the great content!
I'm not sure the compiler decides the memory location of variables as much as the linker and OS.
the compiler can decide pretty much the entire memory layout if you want to, but usually it doesn't because PIE allows the kernel to randomize addresses for security reasons. if you compile the following:
'#include
int main()
{
printf("main: %p
",(void*)main);
return 0;
}' with the -no-pie flag (for gcc) it will always output the same address. of course that address is picked by the linker, but thats part of the compiler in my opinion. (and you can of course write a linker script to tell the linker exactly where you want your code, if thats important to you. but the kernel might not like some address you are trying to get if its reserved for kernel use)
anyway, i think that what the video referred to is that the compiler decides the layout of variables on the stack, not the absolute address of the variables, just their relative offset to each other. same for statically allocated variables, the compiler decides their relative order and padding and all that on the .data or .bss or .rodata sections
The order is defined by the compiler.
Defining the exact location depends on different things and will be assigned by the compiler or the linker.
This issue is why I disagree with them no longer teaching ASM as the first language. When I went started college they expected you to take ASM before you could take C.
I've never known a programmer who came from that system that had issues with understanding these and other more complex issues. Sure there were lots of people that dropped because they couldn't handle ASM. I honestly think the programming world is better for that.
Assembly language is a terrible first language.
I recommend that you delve into this just a bit further. Is "Watch" on a variable useful for something like this? How so?
-"your variables are not real, they cant hurt you"
my brain after stalling for 15 minutes trying to find an adequate variable name: "..."
Jacob. Since in the von neumann architechture code is memory, can you memcpy a function into a buffer and execute that buffer?
That sorta sounds like a buffer overflow attack. Say you have an input field, the attacker essentially write enough data into that field that it reaches the code section of memory. This can be used to run some code
@@case_sensitive depends on where the buffer is located. If the executable buffer is in the heap theres no guarantee that the input can overflow into said buffer. Especially not when the input is on the stack
Perhaps a recursive function would provide a demonstration that "there's not a single bucket labelled A".
Until you choose some tail-recursion examples where it actually can be. If you start thinking about variables as anything more than an abstraction of storage (to be resolved by a compiler) with a specific life cycle, there is likely to be some edge case where your simplification no longer holds true.
you know what is even worse to debug? giving a value to a pointer to function (The address of a function)-> check if that value is NULL. you find it NULL THOUGH you gave it a value which is a function name. but if you give a value to a that pointer which is the address function -> call the function once using the pointer -> check if that value is NULL -> now it's not NULL. why? I DON'T KNOW. and this makes me crazy.
Variables don't have to exist in memory at all. If the compiler can use a CPU register all the way to represent a variable, it will do so and no memory is ever assigned to that variable. Of course, this will only wok if you never use `&a` to get the address, as a register has no address and that way you force the compiler to assign memory to that variable. A compiler may even assign neither memory nor a register to a variable if it doesn't have to. E.g. consider this code `int a = getA(); useA(a);` The compiler can turn that into `useA(getA());` and thus won't manifest the variable at all by just passing through the result of one fiction call to another one, and how that works is platform specific; it might use memory or registers or neither. Even if it uses register/memory, that isn't assigned to a variable, just use a temporary storage. Also if two variables never overlap in usage scope, the compiler may use the same memory for both of them to save memory. E.g. "int a = ...; /* 1st code that uses a */ int b = ...; /* 2nd code that uses b but never a */` If there is no way to get from the second code back to the first one, why shouldn't a and b share the same memory? However, most of that will only happen if you build with optimization enabled as a compiler must perform some analysis to know which variable scopes do overlap, which variables can be passed through directly, and which variables won't ever require memory and can just be a register.
What would be a quick fix for this? Defining a const variable ?
const variable is just a syntactic sugar by the compiler to prevent the programmer from changing that variable before doing compilation, where in real life nothing is "const" the const variable can change if you change the location of memory it holds, the same goes for private members of a class and everything else, everything is changeable if you reach their memory address
Great video! Also, variables are just zeros and ones, if we all agreed on a new arbitrary way of representing numbers in binary, the same variables that seem so clear today would become nonsense. We know 0001 == 1 because we all agree on it. That's the importance of standards
Reject reality, free() your life.
nice video, maybe we can regard all variable as a pointer that point to some places in memory. then we must know which places we want it to points to and make true it do not point to the places we don't want it to point to
a is zero * pointer. *a is one * pointer. **a is two * pointer.
my english is not good, hope it is clear
I think it is counter-intuitive to not refer the black board as a "stack". Also it would've been useful to expand on the idea by explaining objects and the heap, because a variable always points to memory on the stack, but the value on the stack contains all information to find the object on the heap, like address and size.
The stack is just a piece of memory just like the rest of it. You can allocate a chunk of memory with Malloc and then just use that as your new stack
Not true.
The story holds also for global variables.
They are not on the stack.
Besides that, the compiler can store variables into CPU registers in stead of memory.
@@maxaafbackname5562 You are right, the heap is also used for data that gonna outlive the call stack, my bad.
Gonna be honest this one disappointed me a little, not cause the video was bad! But because I was expecting it to be about how the compiler waits to actually initialize variables until they’re used. Like if you debug a program, have a bunch of variables assigned, then do a few lines of arithmetic, break on the first like of that, then any variables not used on that line just dont exist to the debugger… sometimes at least. Reasonable behavior but a little annoying sometimes. Was hoping to learn more about it
Just a little tip: make -B to cleanly build
Be aware: it removed all my CPP code.
Hi Jacob! I really would appreciate an answer on this. I am just curious why is it you make all this C/C++ content? Seems like C isn't that popular nowadays to talk about and you have kind of made it your thing. Don't get me wrong, I love your content and I personally find C to be my favorite programming language.
IMO you can't properly understand programming without understanding C
entry(main) == 0x1000
(offset 0x1000) = 255 // 1 memory cell = 1 byte = 8 bit
function not real
variables not real
datatypes not real
just description
This is the main problem with people looking at languages like C from a low level point of view. Variables are real in C, your use of pointer arithmetic is undefined, C doesn't target your machine but an abstract machine, C is not assembly and there's no 1:1 mapping between the two. Just because your variables might be optimized away or anything else, it doesn't relate to C at all.
pointer arithmetic
Any chance to get that shirt? 😅 its awesome
I'm working on bringing it back.
Oh nooo, my favorite informative technologies teacher, Jacob-san, became insane! What should I do, after all this, I can’t accept the loss of daddy senpai from my life. Is the world be kind to get him up and mentally healthy after every war with pointers we got through together. /ᐠﹷ ‸ ﹷ ᐟ\ﾉ
Not helpful, there is no functional distinction between the different analogies you used. What you're saying only makes any sense because I already know what you're trying to say for how it works. I'm honestly still confused about what the problem is with thinking of them as "real" is. I guess I don't get what you mean by 'real' since it all would work identically with the bucket analogy... we start at bucket A and move over one bucket... I think the conceptual thing isn't about 'realness' but about layout and indexing.
Don't click your heels, go use sanitizers like Asan, Tsan and Ubsan, and memory analyzers like memstomp and Valgrind. And don't forget regular compiler warnings, get that -pedantic, etc.... And when things are good, we can see if we can make them bad with fuzzers.
Variables are real, but it is just word-named RAM adresses. In C++ there are ways to avoid this kind of overloads... but not in C
Well, processes aren't real either. can we have a video about how the actual unit of work in linux is a task, rather than process? then we could get our hands dirty with the clone() syscall. like, how only fd and/or address space is shared etc. how fork is basically a subset of clone. i'd really love that.
He has videos about that.
@@thebigmacd i thought i had seen those, but i couldn't find them. you mind giving me a link?
is this the reason why C/C++ are not type-safe?
C++ is far more type safe than C and no, this is not the reason.
So is a place in memory real?
your pc uses virtual memory, so the memory your program sees isn't real XD
Yeah, variables are just references to stack/heap addresses.
Not really; I would not say so. Not just the stack (also CPU registers or static segments), and not the heap (because the heap offers dynamic storage duration, and variables do not use it).
They are also not references (which are a high-level concept), but I suspect that you meant that they can be translated to a memory address under the hood - this is also not universally true (it does not apply to register storage variables).
@@swavek_wlodkowski I know, just wanted to underline the fact that variables reside somewhere. And variables in (some)interpreted languages (JavaScript) are on the heap.
@@georgecop9538 This could be right, if not for the fact that the video starts with C/C++ in the thumbnail and the author wears a malloc t-shirt. Then someone would argue that there is a environment where what a programmer sees as a variable is stored in a secondary memory of some remote network host ("databases, I am looking at you!").
They could reference static storage too. That's where thread_local and static come into play.
@@georgecop9538 Not always, variables may in fact reside nowhere. Create a variable, don't use it, compile with -O3, start GDB and look for your variable, good luck.
This is dangerous!
TL;DR C is not an assembly. It's high-level language that abuses memory concept and allows a lot of optimizations thanks to undefined behaviours (delete code that can't be real if you read it as it written, not as you'll think it will run on CPU).
This. The whole "*ackshually* x is really just y" tends to be false in 99.9% of cases, and are often just misconceptions because people believe that there's a 1:1 mapping between assembly and C. Just because x can become y when compiled, doesn't really say anything about x or y.
variables are alias for addresses, nothing else
a c varibale is adress + data type info or the compiler does not know what to do with that start of memory location where the variable begins at
The universe isn't real, why variables must be ?
Floats are not real. Real numbers are associative. Floats don't.
Variable exist in memory and registers. Therefore they are not real. ow totally lame.
Honestly I feel like this title is clickbait
I already known all u tried to explain here and I still think they are "real". U could use this type of logic to littelary anything. What u see with your eyes is not real! It's just separate waves that your brain process and I can demonstrate that by using glasses. U see, image is different so it's not real!
U can still use bucket analogy to explain this.
"buckets have different sizes and if u try to add to many water to them they will overflow to next bucket".
U littelary removed buckets to add squares that were doing exactly the same thing as bucket. And pointer is just pointing to the bottom of bucket..
Video itself is as always very good, but this metaphor about lack of existence feels silly, silly enough to make it feel like clickbait
This is a great video, unfortunately with a terrible title. I suspect it's for clicks, but bounds checking is such a critical concept. I wish you had named this something different. Just honest feedback, otherwise great work man.
Also good way to protect yourself from buffer overruns is to forgot abot dynamic arrays concept. They aren't real. If you really want them, just implement for yourself arenas using realloc and _write_ your code as operations on memory, not in OOP terms. OOP is generally bad idea, you just spending your time to it instead of writing code that does something (like a tool for specific job) and name your functions and types (structs, unions, complex stuff) like folder names, from top to bottom.
What about making videos on rust.
Variables are not real when they're declared int!
No. Your variables are 'real' fsvo 'real'. Buckets is a perfectly good analogy. Everbody understands that buckets come in different forms and different sizes with different capacities. What you're trying to demonstrate is that your buckets are somewhat fragile and that the integrity of your buckets can be compromised if you get your code wrong. Well that is perfectly true, and a valuable lesson, but I don't see how making out that variables are not 'real' is helpful to a beginner... and you don't define 'real' in any meaningful way anyhow. And your title is annoying clickbait.
Variables are very real. They have a name and they hold a value. CS 101.