Yes, they are not real, they are integers.

Variables aren't real, they can't hurt you. Variables: Segmentation fault

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.

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.

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!

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

I'm not sure the compiler decides the memory location of variables as much as the linker and OS.

Sounds to me like ‘C’ stands for ‘clobber memory’, lol. Thanks for all the great content!

Jacob. Since in the von neumann architechture code is memory, can you memcpy a function into a buffer and execute that buffer?

"Size doesn't really matter here" what a chad 🗿

I recommend that you delve into this just a bit further. Is "Watch" on a variable useful for something like this? How so?

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*

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.

What would be a quick fix for this? Defining a const variable ?

Perhaps a recursive function would provide a demonstration that "there's not a single bucket labelled A".

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

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.

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

Reject reality, free() your life.

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.

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.

Just a little tip: make -B to cleanly build

-"your variables are not real, they cant hurt you" my brain after stalling for 15 minutes trying to find an adequate variable name: "..."

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.

entry(main) == 0x1000 (offset 0x1000) = 255 // 1 memory cell = 1 byte = 8 bit function not real variables not real datatypes not real just description

Any chance to get that shirt? 😅 its awesome

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. /ᐠﹷ ‸ ﹷ ᐟ\ﾉ

pointer arithmetic

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.

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

is this the reason why C/C++ are not type-safe?

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

This is dangerous!

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.

So is a place in memory real?

Yeah, variables are just references to stack/heap addresses.

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.

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).

variables are alias for addresses, nothing else

The universe isn't real, why variables must be ?

Floats are not real. Real numbers are associative. Floats don't.

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.

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

What about making videos on rust.

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.

Variables are not real when they're declared int!

Variables are very real. They have a name and they hold a value. CS 101.

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.