A const int is not a constant. 

Macros are not C "constants"; they are literals. They compiler does not even see macro definitions because they are preprocessed before compilation. They are only constants in the sense that literals are a type of constant, but again, the compiler does not see or process macros. If you look at the preprocessor output, the macros are completely gone. Enums are the only symbolic constants in C. They are evaluated by the compiler, so they are part of the C source code, but are literals in the code. The definitions do not take up code space. Code space is only used inline when they are used in the code in place of literals. Literals cannot be accessed by address in C, it would kind be nonsensical to do so. Literals only take up code space inline with the code. They can only be addressed if the literal is in an initializer for a variable. Then the literal value can be shared, directly or indirectly, because the variable has an address. The const keyword is for access control for variables and parameters. The literal values that form the initializers of variables can then be shared because the address is part of the code space and that address can be shared. That means for static and global variables, the initializer is evaluated at compile time and that instance is stored with the code. For non-const variables, that structure is copied to a RAM location at startup, so the storage is really doubled. There's a copy in code and then in RAM. This is true for locals, as well, except the RAM copy occurs upon function entry, not at program startup. I mainly write firmware these days, so const has a special meaning in firmware development, assuming the code is running in flash. The code, including initialized variables, is in flash, which is non-volatile memory. They truly cannot be modified at runtime. It is more than just access control. In firmware development, vendors ship libraries with gobs and gobs of macro definitions for constants. The main reason for this, I believe, is that all of those definitions simply go away after the preprocessor phase of the build. That's a good thing because 99% of those definitions go unused. Although that isn't conditional compilation in the logical sense, it kinda is because the definitions are only selected when they are invoked. In that sense, all macros are conditional compiling. Contrast that with enums, which take up no space in your code image, but are still compiled. Contrast that with const variables, which are both compiled and take up space in your code image. I hope that is not too confusing. I find much of this hair splitting doesn't matter unless you are writing firmware that runs in flash. In that case, understanding this stuff is important because RAM and ROM are both precious resources.

Up for a challenge: Enplane to the newbie C programmer the differences in use of volatile , const, and static as applied with scope global, file global and function. Good luck. Fifty years of coding in C (yes, it is still my goto language) I still sometimes get tripped up. But all languages have these problems, as in: Throw the horse over the fence a bale of hay.

This is a Video that tries to talk about the intrinsics and fundamental behaviour of 'C' - but fails horribly at that. What do you mean by "is a constant" ? Cause C does not have anything that "is a " constant. You can have a "constant expression", or the keyword const that is a type-qualifier. "const int A = 10;" IS constant. The compiler is allowed to move it to a read-only section and if the address of 'A' is not taken, allowed to omit it. "we could use pointer tricks to actually change the Value of 'A'" No you can not - that is by definition undefined behaviour and most compilers will not let you do that but just ignore your code that attempts to do so. Feel free to try it out... or rather: YOU REALLY SHOULD HAVE TRIED IT BEFORE making those false statements. "const int A = 10; const int B = A + 1;" - yes, that is not allowed cause it is not a "constant *expression*", not cause it is "not a constant". This is a quirk of global lifetime and initialisation. The most frustrating thing is that you are #constantly talking about "a constant" which is just not a thing that exists in C.

Cppreference: "Constants, by their simplest definition, are values that do not change." const x is, quite literally, a constant. If you declare a macro equal to 10, that's a literal expression (and yes obviously it is a constant expression).

It IS a constant. Just not a compile-time constant (such as pre-processor defines, enum values, and C++ constexpr values).

2:17 You can #undef and then redefine with a new value. It's not really a constant, just a macro

It is worth remembering that when coding for many microcontrollers "const" will place the value in the program store (often times Flash). From a practical point view this means the value will be read-only. This just an addition to already excellent video.

Hey Jacob, I'm a colleague from a couple hours north on I85. I love the idea of talking about const and literals in C. But be careful that students will watch videos and take the content as gospel. Then C instructors will need to spent 30 minutes clearing up misconception introduced in this video. And then they won't believe you on your next video which is a shame because they are usually pretty good. So it's better to get them right the first time. The fundamental thing is that there is no such thing as a constant in C. It's a word we still use colloquially because it's a good short hand. And It's unfortunate that K&R used the word constant in their original grammar. But the programming world has been calling them literals for decades now to clarify the meaning. So you have literals and variables of const type. And they are not interchangeable in the language. You can't write on a const int in C. Even if you do weird pointers things to get the right address. Writing on a const in C is undefined behavior. It may work on some systems, but it's not C standard. I've seen architectures where the const variable get mapped to ROM, or a RO data segment, or just to a regular segment of memory. And so in practice I've seen writing to a const with weird pointer tricks that would change the value, be ignored, or lead to segfault depending on the architecture. I like the idea, but the execution is, I am afraid, confusing to students. I'll gladly review scripts of video if you want. Not that I know better, I probably don't. But sometimes, two sets of eyes are better than one! PS: And I understand the difficulty of crafting a perfect video! I recorded an entire map/reduce video lecture where I mixed up cross product and cartesian product. My students had never been so confused!

Actually literals in C (i.e. what #define's produce) do have a type - which can be affected with suffixes like U, L, LL, Z, etc. - and the compiler is aware of it. Might be an interesting topic for a video.

In C (and any language really), the guardrails are there for you and not the machine. Everything depends on your willingness to engage with the languages’ constraints in good faith (unless you’re just breaking things for fun)

10 is a integer literal. And that is by definition constant. In C a constant (variable) is not the same as a literal.

What do you mean under "constant is not really constant but read only entity since we intialized it"? How else would you describe or define constant if it is not just read-only entity?

Not to state the obvious but a const int will be a constint and not a constant. I will see myself out

Since you have posted a clarification video I'm surprised you have not changed the title to this one and also have not pinned a link to the clarification (which has far fewer views than this one). I think K&R expressed what a const is quite clearly: "The qualifier const can be applied to the declaration of any variable to specify that its value will not be changed." and they also say: "The result is implementation-defined if an attempt is made to change a const." So your correct when you say that a const is a read only variable. Also, they use the words "consent expression" to refer to a literal or combination of literals with arithmetic operators. They use the words "symbolic constant" to refer to the name part of a simple macro and constant or constant expression when referring to the part the macro will substitute in. It should be apparent that the word constant is used here in different contexts and so It seems to make no sense to say a const int is not a constant. It is a read only variable and in that context it is a constant. K&R (2nd ed) also says the following: "The const and volatile properties are new with the ANSI standard. The purpose of const is to announce objects that may be placed in read-only memory, and perhaps to increase opportunities for optimization. The purpose of volatile is to force an implementation to suppress optimization that could otherwise occur. For example, for a machine with memory-mapped input/output, a pointer to a device register might be declared as a pointer to volatile, in order to prevent the compiler from removing apparently redundant references through the pointer. Except that it should diagnose explicit attempts to change const objects, a compiler may ignore these qualifiers."

Great video, in embedded systems we usually use "volatile const uint32_t *reg = 0x04000000u;" to describe a read-only register (like a hypothetical UART RX DATA register). It's not possible to write to the register, but we can read from it, and each time we read it we can get a different value ! And the volatile make it even funnier.

And this is why constexpr was added to C++. Edit: It's me. I'm C++ people.

In embedded C const makes perfect sense. Const means variable is stored in ROM (flash), so you cannot change it's value. You can read it, you can copy it to RAM, but you cannot edit it. int a = 5, stores value 5 somewhere in flash and copies it into RAM in init routine. const int a =5, stores value 5 somewhere in flash and you access a from RAM.

I tested the pointer thing in c++ and I got different values at the same address. Code used: int main() { const int a = 42; int* p = (int*) &a; *p = 69; std::cout

Oh dear. Yes, we know… This is why, if you want to define a commonly used literal, for example, you’d always use a #define - it’s pointless to have a const definition for a literal number, mostly. It does save a little space to use const for 64 bit ints, or double precision floats, though - since compiling the address of a const double occupies less bytes than a literal double would (4 bytes vs 8). If you want a bunch of strings, like error messages however, you wouldn’t want to use #define because it would get compiled into the code every time you reference it and waste a whole bunch of space. That’s why you declare it as a const. Same goes for any static data, or lookup tables. Anyone who doesn’t know this difference really has no business writing C code, IMHO.

Reposting my comment, because my comments keep disappearing for some reason. At 04:16 "printf("&A = %p ",&A);" I'd recommend a cast to a pointer to void if you're using the %p conversion specifier. Sure it might seem to work how it's supposed to on most implementations even without the cast, but to be pedantic, this is undefined behavior. The %p conversion specifier expects a pointer to void, and if any argument is not the correct type for the corresponding conversion specification, the behavior is undefined. From the C standard draft n1570 (The fprintf function) (didn't write exactly where it is in the standard draft, because RU-vid doesn't seem to like it if you put a lot of numbers in your comment) (emphasis mine): p The argument shall be a **pointer to void**. The value of the pointer is converted to a sequence of printing characters, in an implementation-defined manner. At 04:30 "We could use pointer tricks to actually change the value of A": Then you'll invoke undefined behavior. From n1570 (Type qualifiers) (emphasis mine): **If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined**. If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.

"C": when it walks like a const, and talks like a const, it's still not a const.

TLDW: const int is a constant at runtime, but not at compile time. The value does not even need to be specified in the same compilation unit, so it might not even be known until the program is linked. But it sure won't change at runtime, that's all. The confusion comes from "constant expressions" which are expressions with a value that can be determined at compile time, and that a const int is not.

const int TEN = 10; // in case ten fluctuates

I've always liked the *EQU* assembly directive for defining numeric literals. More powerful than *#define* for numbers, you don't have to guard your numeric expressions with parentheses. I'm surprised they didn't bring it over yet.

Video starts at 3:05

It seems that from C99 onwards this is valid? clang had no issues with it during compilation? const int a = 10; int abc[a]; int main(void) { return 0; }

I’m a newbie in C and I’m a bit confused. What do you mean with “constant”? Because for me a constant is a function a->b->a, for example the const function in Haskell. What is a constant in C?

Didn't get the problem of switch. Why shouldn't it work?

defining const int A = 10; assigns storage because it has external linkage. If you were to instead static const int A = 10; And never reference to it by address in your code within the scope of the file and compile with optimization, this will NEVER occupy any storage area.

I find myself coding C-like code in C++ just so I can take advantage of things like constexpr and compile-time array sizing.

"A const int in C is not a constant." Lol got it

`enum { A = 10, B = A + 1 };` will work perfectly fine

Finally, a great, interesting and professional C content on YT ☺

maybe we should just add "#define immut const" then instead of const we could declare an "immut int" since "immutable" is understood as something that WE aren't allowed to change. This reminds me of a recurring embedded problem where a microcontroller's hardware allows writing to the input port which has the same effect as writing to the output latch but allows for some tricky read-modify-write bugs. In my opinion the input port should be declared "const volatile".

Hello. What if someone uses mmap to allocate memory with the flags PROT_READ and PROT_WRITE, modifies the value of the pointer, then uses mprotect to just change the flags to PROT_READ? Wouldn't that pointer behave like a constant?

Before making a video on "exotic" constexpr please explain the const used with pointer and how to declare a 1) pointer to const variable 2) const pointer to variable 3) const pointer to const variable I'm programming in C 30 years and with exception case 1 I have always to check books or internet to find syntax for cases 2 and 3

This reminds me of Fortran's numeric literals that are actually variables - they can be modified (mostly by accident) when used as subroutine parameters because of “pass by reference” calling convention.

And what exactly is an 'integer constant' that the switch wants to have? Should the error message instead say 'integer literal' to be more clear?

I'll come back, but apparently I've been programing to long. Obviously they are not the same, although the enviroment they are in makes a difference as to whether you can mess with them. I basically failed an interview some years ago because i said const and some other syntax were promises the compiler inforced. I should have pointed out that the promise could be cercumvented. They apparently thought they were set in concrete.

I know they use the same compiler, but isn't "bool" a c++ specific datatype like "string"?

I am not a hardcore C programmer. I write C for MCU firmware development. I have never used "const" and don't know what is the use of it. If I need something constant I rather use Macro. Can anyone show me when will you use const instead of macro?

Thanks for the video, this is an area where I don't know all the details. Is the C compiler allowed to do optimization for calculations involving variables that are const but not volatile, such as replacing A+1 with 11? Is it allowed to put them in a read-only segment?

How about "#define A ((int)10)" in order to have some type check?

Thank you, I love your course on C/C++ I have learn so much, I really appreciate what you are doing

C23 will add `constexpr` fixing the issues you mentioned

EDIT: I just saw the latest video does mention enums but didn't really show the differences much. Original comment: I'm surprised enums weren't mentioned in this video considering those are an actual way of having a numerical constant which isn't just using preprocessor text replacement to fake it, so the compiler can actually tell which context the enumeration's name refers to the constant and which context it's not being used as a constant. e.g. you can have enum { A = 10 }; And still declare a struct or union or typename called A e.g. "struct A;" (whereas if you use a macro then "struct A;" would just be replaced with "struct 10;" which is not valid)... Although maybe it's not the best idea to have those things all called A in the first place, but still it can be done, and I feel like it would've been worth mentioning in this topic. Also, constexpr was briefly mentioned in the end, but no mention that constexpr is being added to C in the upcoming C23 standard.

So what should I use then if I want to declare a constant in C?

Mentioning C++ people I would more mention the fact that in C++ this is more clear, due to the fact that you can take const params to indicate that you do intent on using that value readonly, then the fact that C++ has tools for compiletime constants

I'd love to see how to do that pointer trick. Don't think I'd ever need it, but it sounds fun to learn.

Hey Jacob, great video. I for one would actually love to see a video of pointer magic on const variables.

Macro definitions (#define) work well as constants if you are using primitive types such as int, float, etc. and that works well and you should stick to that. Macro definitions can easily be identified by all caps and are easily found on top of files, editors also like to show them in green color. It's a very good way to define constants. Unfortunately it is impossible/impractical to define arrays (strings, structs, etc.) with "#define", however for safety of program sometimes you still want to create array objects that cannot be changed (are immutable). This is where "const" comes handy, because it makes sure nowhere in your program you perform a write operation on your array type variables, hence they become constants.

I don't get why you can't use a read-only variable as a condition. The same code exploded to if-else works fine. Sure the compiler might not be able to optimize is as well as if they were literals. But this feels like an unnecessary language restriction. Edit : Switched on - > use.. as a condition

I literally had a technical interview half an hour ago and they asked me this very same question, whether const means constant (of course I said yes)... And youtube of course NOW decides to recommend this.

7:51 I do prefer enum (better would be enum classes) inside a switch...

of course not. in order to make an const int into a constant, you have to solve for its mother's sister. its constaunt. She runs a restaurant with a lot of drawbacks - mainly that she employs only escaped serial killers for cooks and pirates for waiters. The eggs and the toast escape unscathed. So they don't sell well. When we go there, we never get that bread. And when the police come by for coffee, the waiters all make like the eggs and rum.

You did not actually explain what makes a constant constant now. You just showed that it is not the same as #define. And const int ist still read only, so any sane person wont change it. I hope you make a video properly explaining the difference.

You didn't tell us what DOES create a constant

I've got to see the first program where I use "const" to define a constant. I always use the preprocessor for that - just to keep my sanity. Sure, if you define stuff like: #define PAD TIBSIZ #define STRTOP ((TIBSIZ+PADSIZ)-DOTSIZ) "STRTOP" will probably be inlined like some expression but I've never seen a C compiler barf on expressions like that. It's probably a case of constant folding. Advantage is though that constants are always inlined. It saves you one access to memory. Funny thing - in Forth CONSTANTs are done the "const int" C way. But since most of the expressions in Forth using it (like allocating some static memory) are INTERPRETED it doesn't get in the way. My own Forth compiler though inlines constants by storing them in the symbol table. Expressions USING those constants are mostly resolved by the optimizer that does constant folding. Which is funny since it means the optimizer is in essence part of the syntax ;-) I'm not a great fan of "const". I know it helps the optimizer, but apart from (very) basic functions (which we call "primitives" in Forth) it's more often a pain in the neck (when doing maintenance) than a great help IMHO.

As a pedantic asshole, I find this video quite troubling.... But I guess from a layman's point of view, it's informative. Fine. BUT!! regarding the modification of a const-qualified variable via pointer arithmetic, you should be VERY careful to explain that it's undefined behavior in the eyes on the language. That may require a slightly deeper discussion about the language specification and how it views specified/unspecified/impl. defined/undefined, and how all those boil down to conceptual "guarantees" (whether the language, the platform, the implementation, or dumb luck is guaranteeing the behavioral correctness of your program)

C23 gets constexpr

A constant is not a constant, at least not at sea. But perhaps at land it is?

48 things on Git @_@ My 0-notification anxiety is on fire

So why hasn’t gcc fixed this yet?

It's also relevant when you're doing embedded dev and you have a microcontroller with maybe 32kib ROM space (abundant) but only 1kib RAM (scarce), so your variables end up eating into your scarce resource. Then unfortunately every compiler has to come up with its own nonstandard way to declare truly constant constants which are actually in ROM and don't get maintained in RAM.

why dont you use clion?

What about "static const int"?

Malloc shirt. Bruh lmao I love it

I'm very confused. Maybe you should have started by stating what "constant" means, and why a const int is not a constant... Can anyone explain to me?

So basically by constant you mean only rvalues?

the thing to do here is to fix this in the compiler

That's why C23 which adds constexpr is so great

I do like your videos, however, if I may, and not to challenge, just a different point of view, all this depends on the environment. I see a lot of your videos that sometimes dont make sense to me, then I am like, oh, linux type of compile. Example, in this video, const does mean constant to me, and constant to me means a variable in ROM not in ram. I was an embedded engineer (still part time) and const int | long, means the the bytes will be allocated in rom space and they are constant, constantly holding their values. semantics? maybe, but again point of view and environment/platform. "not a constant" depends on what you are perceive constant to be. In my arena every programmer I know (embedded) know that const = constant (as we perceive the word) - all in all, not saying you are wrong, just saying lack of context makes this confusing. I know you are a teacher and that is great, but please add context

That's why i code in C, with a C++ compiler. And thx for the video, i see that my C is rusty. I wasn't aware that dynamic array size (MyArray[A] local variable) was in the C standard ^^', that would be useful in c++ instead of relying on alloca... (or platform specific stuff....)

If you need an int constant with type checking, you can try 'enum'. Usually we think of that as a range of some enumerated type, but you can have an 'enum' type with one element, assigned the value you would like. i.e. "enum ArraySizing(Size=10);" I believe this will get past some of the shortcomings you mention. Of course in C++ there's a class for it, but the enum datatype in C is pretty useful for a lot of these sorts of things.

This video makes me remember that Clang is working on improving constexpr and constexpr in C23

aren't these just scope issues because you are creating the array and switch function in file scope where it is not determined that the const int is initialized yet.

It's a very simple rule: If it exists in memory, it is not a constant. There is a similar problem with "null" pointers. Address 0 exists.

Yea, I tried to use const to get around declaring macros, and rapidly ran into issues. I gave it up. Its too bad.

Excellent video, but the four constant types in C are worth reviewing.

maybe, we should not mix up maths terms and C terms🤔

You can probably force type checking on a macro by doing ((int)10), then it'll tell you about any implicit cast with the right warning flag

it's not a const ant it's a const int

For other embedded system developers: DO NOT use #define with strings, or the memory usage would be bloated

const variables placement is implementation defined - it can be allocated in read-only section - don't write to it - it will end badly eventually

Can you do a video about consexpr

Who needs constants?

Insightful 💡

FWIW: `#define A ((SomeIntTypedef)1)`

it is such a disgrace that the only serious open operating system in the world is written in this language

4:33 you could not. Try it, in a future video. It's a constant. The compiler treats the const as constant and will replace the value as if it was a literal, but otherwise check the syntax as if it was of that type (even if it allocates a sizeof(int) big variable in .rodata and therefor has a pointer to it). That's the point of using const. It doesn't matter, if you replaced the value that it points to, as long as it's not been passed as a pointer into a function, that has not been inlined by the compiler. Stop spreading misinformation by the lack of testing and assuming. Just compile your example with -S and look at the output. If you don't use your "&A" but "A" and use "%d" for formatting, you will see it pushing the value "10" on stack (or to the appropriate registers), regardless of if you change it afterwards. To be more precise, you can't even cast away the const, as the section it will land in will be read-only on most systems and therefor crash if you try rewriting it. Thus it's a constant, yeah it might not be able to be picked up by the pre-processor at all times, but it's still a constant. 8:23 That's not valid. You can't use ints in a case. That's not how C works. It's still a constant. It's not a integer literal. But if you were to call it that, the title wouldn't have been clickbaity enough.... What you did, is redefining what a constant is in C and then say it's not constant, for your 9 minute video of internet spew. Just as Pannenkoeck with his BS excuse of introducing the term half-button-press and parallel universe. Some people seem to celebrate this internet spew...

I can say I switched from C to HolyC (and TempleOS). Would you do an episode on that?

I recall something from many years ago that the C standard says a variable is in RAM even if you put a const in front of it. The const only tells the compiler the "variable's" value cannot be changed by assigning a value to it, and that will give a compile error. Of course many embedded C compilers break that rule for practical reasons.

4:28 you say "Because we can get the address, we could use pointer tricks to actually change the value of A. Let me know if you'd like to see that in a future video. It's not something you would normally want to do, but of course that hasn't stopped us in the past, and most of our compilers actually let us do it even if it doesn't make any sense." I think a lot of people could use a video on why casting a const away and then writing to it is Undefined Behavior, and what UB is in general, showing off examples.

Saying that A+1 isn't a constant is not accurate at all. You're never modifying A at all when you do this operation, and it can be explained with assembly. Of course onstant doesn’t means you can’t do calculus with it. Same when you say that A is not a constant because you can take it’s address and cast it as non const. In C const keyword doesn’t means the memory is not wrirable at all, it means the type is read only. And because C allows a low level access to memory of course you can modify it if you want! You could even retrieve a calling function variable if you wanted to! I think you’re pointing real things about c that can be confusing for beginners, but saying that const isn’t constant is not only confusing, it's also completely inaccurate...

const int is a constant integer variable

The Array creation and the switch statement compile just fine. Even with Warning level set to maximum of 4. I was slightly unsure about the array creation but after thinking about it, I expect it to compile fine. The A and B variables are created by the time the compiler gets to the array creation statement. The switch statement should never be a problem because the const variable is just being compared. A const variable cannot be assigned to unless by pointer or recasting away the const. I suggest you check your compiler and change to a compiler version that works properly.

enum { A = 10 }; /* good enough, int only */

@6:47 The variable length array support is a compiler extension. It's not Standard C++. Compile with -Werror=vla

You had one job!

good old enum trick