Looking forward to the “pointer” video and how they contrast with pass by reference.

2:56 oh yes, this in conjunction with "conditional debugging" covered in #224 totally changed my hobbystic attitude towards Arduino and allowed to deliver faster and smaller binaries written only once. This channel is so underrated!

I just discovered your channel and I am learning so much from you - thanks! Your videos are excellent, they have a nice pace and you are always teaching important details here and there. Ex: on the two State Machine videos, declaring static variables inside functions to keep information to be accessible between each time you call the functions - that’s brilliant and I used to declare global functions for that. Things like that are making me watch a lot of your material. Please keep going! ❤🎉

I love pointers and use them right up to int***. Even on the most mundane tasks to spice it up. Pointer arithmetic and such. You're a great teacher Ralph. Great video. Most people don't realize they pass by reference already when they update a global array within the loop the array name is the reference to the starting address.

Great to have these short videos brushing up on some basic concepts. Sometimes you think you know something well, but after watching a brush up video like these, you can learn something new. Thanks Ralph.

Ralph we need more videos like this!

Great video Ralph. I definitely think that you’re just the guy to explain pointers, stacks heaps etc. I really think that you should in someway illustrate the way things are laid out both in the machine and possibly in the compiler. Otherwise, a lot of times people have a hard time visualizing them and just treat them as some ethereal object floating in mid air. When I was first using C, I came from assembler where everything is used by reference because back in those days memory was typically very very tight. My biggest problem with the C-language was the symbology used. For example one statement would use an ampersand and then the following statement accessing the variable in the very same way omitted the &. In fact in your code you actually have an example of that. Anyway, my vote is for you to keep going with this series…

I've seen countless vids on YT about pointers/references/stack/heap/etc and it's still not very clear to me. You have a way to explain things (and illustrate them with code examples) that make concepts easy to understand. I'm sure it takes some time to prepare such videos. I can't wait to see what's coming (pointers, etc). We're lucky to have you on this platform. Your efforts are much appreciated.

Another great vid at the right time. It cut down the code in my project immensely. Seems you’re on a roll. Thanks 👍🏾🤓

Thank you for concentrating on the why as much as the how.

Very well explained as usual, this cleared the fog!

thank you for such an interesting explanation and examples.

Very well explained. Thanks!

Good explanation, as always.

Thanks for clearing up some of the confusion. Did a Bacon Byte on pointers ever come out? I didn’t see one on a cursory glance of your videos. Thanks again!

Reference is not pointing to the memory location; a reference is simply allowing the compiler to name the same memory location a second (or more) time. A pointer is one memory location storing the address of another memory location. A pointer is like a friend who can tell me where Ralph is hanging out at the moment. A reference is allowing the compiler to call the person Mr. Bacon by the name Ralph if it likes. Once the code is compiled, all references have been resolved into microprocessor fetches from specific addresses; but pointers occupy memory addresses themselves and can store whatever address there we choose to put into it. (Admittedly, some type-casting might be required...)

Nice information, thank you for sharing it :)

Been a while, but the old IBM Fortran compiler had a quirk. Since the machine was only had 8 bit words, they didn't want to waste storing lots of numbers. So, if the compiler used an explicit "2", it was stored in a 16 or 32 bit location, with an 8 bit pointer (the 360 only had 4k code pages, and was paged --a lot-- to get larger code). Any time you the literal "2", it would access this location. Thus, when you called a routine, say, sin(2), the compiler passed "2" by reference. This created an interesting code trick. Make a function INC(N) which adds one to the argument and returns the updated value. If, in the code, you said N=N+1, then using 2 later in the code would always reference 3. They fixed this pretty soon.

I find the C++ 'const' placements in functions mind bending; it looks like there are 4 or more possible places that inform the compiler to check different things. Do you have any succinct guidance or video as the topic seems relevant to passing by reference? Excellent video - as usual.

Another good video, thanks. What debugger are you using please?

I've put off this video until today, I really wanted to watch it, but at the same I didn't.. cause I wanted to have the right mindset and I think I have it today as I believe I understand the difference quite well from your description of it. Going to try and have a go at it tomorrow to see if I can find any difference. I do seem to have some memory overflow or what its called, so after a while certain functions are just not working as they should, while others are still working, until a restart of the unit. Also, another difficult problem is that when I program an 328p with flash content above a certain value, the program just doesn't want to run properly. It is a bit hard to explain, haven't touched this specific issue for a couple of months as I can't figure it out.. But.. the feeling I get is, when I have a sketch of.. say 60% full of the flash, it feels like the sketch is overwritten, like the actual memory in the chip is too small so that it starts overwriting at the start of the flash memory area.. which of course could be possible with counterfeit ICs.. but these are bought from Mouser and Farnell so I doubt that is the case - at least I hope.. Then, if I remove some code - no matter where in the sketch or its underlying files - so that I get under 60% full, the sketch works perfectly.. I took this on Reddit a few months back when I was trying to figure this out and they talked about the heap or stack and for me.. this is "invisible", so how would I know if I fill up the heap/stack or if I have a lot of it left? Do you have any ideas, thoughts or maybe plans on a video about heap/stack or so? As always, love your videos, you're very methodical and "slow" which I really, really need 😂😃

Passing by reference is much better if your passing a large amount of data, as the reference does not take size in to account. only where it starts so your heap remains more of a mole hill, not a mountain .

good points all

The only difference between ByReference and Pointers is more for the benefit of the comipler to type check. They are both real 'pointers' passed to the function on the stack as opposed to an absolute value passed on the stack. The best way of showing the difference is by showing the assembly code that is generated by each method. Passing ByValue only temporarily copies when its poped off the stack in the function. It's then discarded whrn the function goes out of scope. ByReference/Pointers is way faster too and requires less stack size.

hello, can i ask what external serial monitor program is that you're using? Seeing "Save" on it made me realize I needed that functionality for so long!

I have to revisit the episode; it's a double-edged sword. Look at the definition of Arduino core EEPROM put. I repeatedly called get() and put() and experienced some very confusing results. The header file EEPROM.h contains: template< typename T > const T &put( int idx, const T &t ){...}. My question related to this is, what changes the caller's behavior with the use of 'const' for parameter &t? Cheers, and by the way, I'm looking forward to hearing what you have to say about pointers.

5:38 You mean the stack, right? All function parameters (In C and C++) are stored on the stack, even those passed by references (addresses) are stored on the stack.

lol. hell yer this always catches me out :) cool video :)

To get behind the 'blackbox' of libraries, you can debug your code, (line by line). You can see this in the ESP32 series when after your code, and the Arduino code, it will jump into the FreeRtos and show you what is being called behind the scenes. Unfortunately Debugging Micro-Controllers requires Hardware, and that's an additional cost

probably could have dove into what the compiler actually does with those args in a typical ABI in the same amount of time, no need for analogies.

very nice topic, quite difficult in fact. I am sure if you go further with this series you will touch the key words: stack and heap ;-) Unless you won't ;-) At least for me it opened the eyes. Especially when we program for the devices having kB memory (not GB) every bit counts.

The other half of this equation is why we have the first. Beginners will start to notice that functions are always return by value and often a little cumbersome to get much of any complex data out of them. This results in broken code that often runs perfectly fine 99 times out of a 100 and crashes hard the other time. code like: SpecialObject getMySpecialObject() { SpecialObject myObject; return myObject; } Which will actually work, but not in the way you expect maybe. It creates multiple copies of myObject and destroys one of them. Much worse is things like this: SpecialObject *getMySpecialObject() { SpecialObject myObject; return &myObject; } A very common mistake of returning a 'pointer' to memory allocated on the stack that is immediately deallocated on function exit. I myself got caught out recently by a function which did this: void debug( char *str ) { char outputStr[ strlen(str) + 2 ]; strcpy( outputStr, str ); outputStr[strlen(str)] = ' '; Transmit_DMA( dma_channel, outputStr ); } The trouble is, the Transmit_DMA returns immediately. But the memory it's using was allocated on the stack and the very next function call writes garbage out the DMA channel! It was quite amusing to me, but with 20 years experience it didn't take me too long to go "Ohhh.... DUH!" and fix it. That could stomp a beginner for ages. Note "references" in C++ use similar syntax to pointer references in C, but behave in different ways. References have restrictions, like you cannot have an uninitalized reference and I'm not sure if you can reassign a reference, say in a function. It's been a while and I just don't like C++ because it has far too many different incompatible ways to shoot yourself in the foot and the errors it spits out are, somehow!, even worse that C! C is a known quantity, C++ is polymorphic in many of the wrong ways, you can't quite be sure without studying the 1000s of pages of language committee publications about what flavour it is this year.

If people like to torture themselves cppnuts have some incredibly rigorous 8 hour courses on pointers, arrays, vectors, binary trees, linked lists. I love following along and doing all the homework and such.

With one version of Fortran, one could have a numeric constant in the source, pass it by reference (as everything was) and change its value - bob(2)... FUNCTION bob(A)... A=1

I have been programming since the 60s. The muddle for me is not about the concept of value vs. pointer vs. reference (don't get me started on Algol "call by name") but figuring out which way the specific language notation is pushing the implementation. The notations all look too much alike.

I'm gonna start making all my variables global variables, just to trigger your angry faces 😂

One day before I die I hope I will get the hang of all this🙂

Sorry Ralph, a bit like watching paint dry. LOL

tl;dw: difference is in memory usage. and now i'll watch and confront ;p

Over my head, sorry. No idea where this would come in to anything I work with.

Nice video again Ralph, thank-you. I keep hearing that 'Global' variables shouldn't be used but nobody ever explains why. Why are 'Global' variables so bad? I use 'globals' all the time and never have a problem, so is it just an excuse for bad coding practices? Less efficient? The easy way out? Maybe my understanding of what 'Global' variables are for is wrong? If they are as bad as everyone keeps saying they are then why can they still be used? I dunno....political correctness gone mad perhaps?

By reference is one of those things I don't really understand why it's there. At machine code level, it's pretty much just a pointer. c++, why are you so weird lol