@phillipwombacher9635
im a nurse teaching myself code who has no prior experience with coding and am a month in and this was the best way I have heard this explained thank you so much for this!
@krazyolie
The other way this plays out is how you can use sizeof on the array to get its size but in three pointer it will just return the size of the pointer.
@rty1955
Brilliant explanation. I am a mainframe assembler programmer since 1969 and your explanation is clearly visible in assembly. I can see how C programmers can get this very simple concept incorrect. Thank you for your concise explaination
@MakindoLearning
Been a fan Huw for over 20 years. Was a delphi user. So pleased to see you still.teaching.
@butchdean
So many seasoned C programmers need to see this. I've had other programmers fight me over this!
@ivanmaglica264
This is one of those things that keeps getting out of my head and I need a refresh. Thank you!
@algorithminc.8850
Great video. Will pass it along, saving me from explaining it. Thanks! I look forward to scoping your channel. I like exactness and accuracy, and great to see someone who believes in such. Subscribed. Cheers
@theosib
Also try applying sizeof to an array vs a pointer.
@ruslanzalata
It's so nice to discuss pure C features as all of them can fit into one head easily, opposite to C++.
@jeffspaulding9834
This is fantastic. I struggled with this in my early days of learning C, since I couldn't build a good mental model around what I was seeing. Eventually I built a good enough mental model that I don't generally have issues with pointer decay, but this clarified a lot of things. Good stuff to think about!
@TrinitronX
The way it was described in the K&R book is the reason so many students learning C struggle with the subtle difference between pointers and an array. Arguably, both the 1st and 2nd edition's wording is still confusing for a lot of new learners. When thinking about things like this a bit, I tend to wonder how the world might have been different if some things while learning the C programming language were made more clear, and perhaps many problems with pointers were avoided altogether in the language design. A few more thoughts about how to explain the difference between array of chars and pointer to a char: - char * foo = "bar"; - Can be thought of as literally a pointer to a single "char", which the compiler treats as a null-terminated string, "bar\0" - It stores the address of that "char" in memory, and can be assigned another address later. The stack variable therefore contains the space needed to store an address of a null-terminated string of "char". If it's declared with an initial value, "bar\0", then the compiler places that into the binary at some location, and initializes the pointer variable's value so it points at that location. - char foo[] = "bar"; - Can be thought of as a "static"-ish array of characters, allocated at compile time to the "static" string "bar\0" - It is known at compile time, and is "static"-ish in the sense that it won't change, or perhaps we can say it's "constant"-ish in the sense that it can't change. In other words, the compiler takes the code, sees an array of characters defined and fully known at compile-time (when initialized), and creates an address on the stack to hold that string. As a result of compilation, the array's address and value are the same, and it points to this location holding the string, "bar\0". I like the term "static" here because it is similar to how the compiler can statically compile objects and put them in the resulting binary. In the example, it's putting "bar" into the resulting binary as a "static" string. However, to avoid confusion with "static" do read the following... *Note:* I'm trying to be careful with terms here... saying "static"_ish_ and "constant"-ish because both "const" and "static" are already keywords with overloaded meanings. So, although similar, it's not exactly the same meaning as "static" C keyword, as that implies "static" storage duration and defines behavior for an uninitialized array. Meanwhile, the array example instantiation in the video, and above has the implied "auto" storage duration which does not define what the contents of an initialized array would be. In other words, an uninitialized "auto" storage duration array has indeterminate contents, which could be garbage values, or whatever emergent behavior that the combination of operating system, machine and compiler implementation create. Luckily, in the case of the examples in the video and here, we are initializing both array and pointer to something... so we can sort-of gloss over that when trying to understand just this particular aspect of the language. (Alas, even my attempt to try and explain it is probably confusing)
@टिरंजननकले
Excellent video. Any books for mastering C and algorithms, do you recommend?
@francoisgueguen1012
Very clear, thank you
@JuusoAlasuutari
As many have pointed out, an array is not an address. Claiming so just sounds like being confused about pointer decay.
@Lord-Sméagol
It really helps to understand what your C code will be compiled to to write good code ... and it helps debugging!
@notpythonics
8:10
a c-style array decays to a pointer
constexpr int arr[3]{ 1, 2, 3 };
const int* ptr { arr }; // arr decays to a pointer that points to its first elem
@RussTanner
Wow. I am learning C right now and THAT clears a lot of things up. Thank you.
@Latrocinium086
Great video. Just subbed. Explains some of the subsequent problems and peculiarities.
@j-p-d-e-v
great video! I'll definitely use your book for my C study in the future.
@PauloConstantino167