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

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.

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

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.

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

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!

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)

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?

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.

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.

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?

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

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

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

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.

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

Video starts at 3:05

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.

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

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.

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

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.

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

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?

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

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

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.

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?

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

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.

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

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

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

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.

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

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

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

C23 will add `constexpr` fixing the issues you mentioned

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; }

Insightful 💡

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

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.

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

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

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

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

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

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

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

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

C23 gets constexpr

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

Can you do a video about consexpr

That's why C23 which adds constexpr is so great

So basically by constant you mean only rvalues?

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

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.

why dont you use clion?

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.

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

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

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

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?

You didn't tell us what DOES create a constant

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.

What about "static const int"?

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

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

Malloc shirt. Bruh lmao I love it

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

So why hasn’t gcc fixed this yet?

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?

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

good old enum trick

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.

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

*(int*)A=100;

You had one job!

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.

In C# you have readonly and const..

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

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

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)

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

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.

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.

_Good ole C_

const int anople=330;

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.

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

Who needs constants?

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

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

C23 is getting constexpr.