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!
Yes, it will be interesting. But remember that C++ makes it easier to pass parameters using references; pointers are C old school! Sometimes, however, needs must.
@@RalphBacon I've seen C old school pointers in the STM32 line HAL. It drove me crazy figuring out what was going on until I realized they were using addresses & pointers. I'm looking forward to the video on pointers also.
I’ve seen pointers being used when looking at various programs in the libraries. So far I haven’t encountered a need to use anything other than pass by value and pass by reference. So I always wondered under what circumstances I’d need pointers instead. When I use pass by reference I find I’m more often doing it to keep the heap size down when passing long strings to functions rather than because I actually want the function to alter the value - usually I don’t want the function to alter the value - but I pass by reference anyway to keep heap size down. I wonder if there is a way that as I pass the parameter I can tell the function it is a constant (when in the main program it isn’t) and then pass by reference to keep heap size down, but be free from worries that the function will change the value - ie because it can’t, because to it the referenced value is a constant.
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.
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.
@@RalphBacon it's my favorite language. I have add though Ralph so I'll code for a week straight then not code for weeks. So I'm always out of practice but I understand all the concepts. I need more work on library and class creation. It's gets boring making up bogus entity's to learn. I have a project I'm working on now though where I use vector math and dot products. I'm not one who copies code so I'll hammer away at something for 2 hours that I could've just copied and pasted and not understood more. I have a 32x32 led panel that I put together and I'm making as many of my own effects as possible that cycle in the background very dimly while the screen displays real data like appointments and date time. Hoping to add a cat locator eventually because the display is for my wife who works from home for the government. She floats around the province so there's no place to put her lol
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.
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…
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...)
Hold your🐴horses, Byron, we haven't covered pointers yet. And I did say, quite distinctly, that references were not pointers. They could be viewed as aliases. At best, they were pointer-like (in the sense that there was no additional copy of a variable passed in). But let's wait for the pointers video... I don't have any pointer friends, by the way, they are too fickle.
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.
Yes, all parameters (variables) get pushed to the stack; objects go onto the heap usually. Useful to remember that the Arduino String gets created on the Heap and turns it into Swiss Cheese as it is amended , making it difficult to find a large enough contiguous block of memory for other objects.
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.
Well, maybe; By Reference is one of these new-fangled constructs that C++ allows for _our_ benefit, inasmuch that it abstracts away the complexity and danger of a pure C-style pointer. For example, you don't have to dereference a By Reference parameter. Nor can you suddenly assign it (to) another variable. But these points will be "addressed" (geddit?) when we do the pointers video. Probably.
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.
I'll add it to the list of things to show my viewers. Just remember that 'const' variables can only be set _once_ and thereafter they are fixed. The compiler can then compile more efficient code.
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.
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!
I can't remember if I did that pointers video or not; I may have baulked at it, given that pointers in C++ are generally frowned upon because they are usually not really required (except by ex-C programmers.
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.
The use of a template means that the data type does not have to be known at compile time; it works it out at run time. Pointers are quite straightforward and almost unnecessary in C++ programming (unlike C programming).
@@RalphBacon I added the 'const' in your PassByReference code: passIntByReference(const int &myInt); it's like the function says, "I need the reference location in memory to the variable, but I promise not to change it." Indeed running the modified code will give the compile time error: In function 'void passIntByReference(const int&)': PassByReference:27:21: error: assignment of read-only reference 'myint'. That was nice of put(). :-)
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 .
@@RalphBacon , ahhhh, penny dropped. now I see a practical use. would love a simple demo code that could demonstrate that advantage, in tems of memory use or data copy time. But not sure where to start in developing such a demo??
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'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 😂😃
You can call this routine to tell you how much stack memory (SRAM) is left: // Check stack space void checkStack() { unsigned long remainingStack = uxTaskGetStackHighWaterMark(NULL); Serial.print("Free stack: "); Serial.println(remainingStack); } Free memory is what is left after the heap and stack. Call every few minutes to see if it changes (normally does, sometimes significantly). Although you _might_ be able to upload a full 32K of program memory, it would be a huge program. It's the variables you have to watch (SRAM/Stack), shown after every compile.
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
Single-stepping, real time debugging is essential in some instances (like C# in a dot Net environment) but for ESP32/Arduino work you can always press the F12 key to see what is being invoked during programming too. Quite an eye-opener sometimes. Not quite the same as actual debugging, but then again we're not trying to debug the framework (in dot Net terms we would "step over" that bit). The new Arduino IDE 2.0.x supports single-stepping if your processor supports it. I showed it in one of my videos #180 th-cam.com/video/ArUzVt9z1ug/w-d-xo.html but it was very flaky at the time using a beta (barely) version of that IDE.
@@RalphBacon Yes I have my EP32 Debugger hardware on the way, not as simple as pushing a Button/Shortcut in VS, but it is what is. I'm learning something new everyday with MC's, now it's JTAG
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.
Returning pointers to variables or objects that have gone out of scope is a common programming issue. I fell foul of it just the other day, and could not understand why I could "see" the correct variable (a buffer) for just a fraction of a second, then just "null". Ho hum! (Hangs head in shame). But the fact is, with robust programming practices there is nothing intrinsically wrong with C++. But it is not very forgiving (see first paragraph) and doesn't give any beginner-friendly messages ("Object you are referencing goes out of scope before it can be read") so we just have to be methodical and test more than the "happy path".
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 wonder how a literal (rvalue) was updated like that? On return from the function it suddenly had a different meaning... sorry, my brain just rebooted.
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.
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.
Are my viewers ready for the differentiation between stack and heap memory? I'll consider how best to address this so that beginners can understand it.
That's a shame, Jorgo. But if you continue just Passing By Value, (which is the default way of doing things) your code will be fine. Just be aware that your function that you have called can never change the incoming variable unless it is Passed by Reference. Not a deal breaker for general hobbyist work.
And I edited this down to 15 minutes too! 😢 Oh, and if you just think it's just memory usage... well, double check your code that what you _think_ is happening _really is_ happening 😲
@@RalphBacon oh how i love to learn by prooving myself being wrong ;) Actually i am not C/Arduino programmer (Perl here), however concept of "referrence" and difference between it and "intermediate variable" was clear for me on "this results in what" sense. Never actually took as deep dive as you did here and was satisfied with code working as expected in any case :) Thanks for your video, of course i watched it will the end (even without skipping sponsor message ;P)
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?
No problem with global variables if you have a small program, like on a microcontroller. Once you have 100's of source files with squillions of lines of code then they're a problem - because it is hard to know what is going on.
Good question! I have answered this before but it's basically not a technical answer. Global variables work. They are not inefficient (although they do remain in memory forever). But it's very sloppy coding. Certainly not Best Practice. Those variables can be accessed by _any_ function, not just the one(s) requiring them, now or in the future. The 'scope' of all variables needs to be controlled to avoid problems. I'll do a more explanatory video on the whole topic one day soon.
Global variables become difficult to manage the larger your program becomes, because their scope is not "contained" to a function or set of functions. If you're writing small bits of Arduino code, then they are pretty harmless but if you start writing much larger programs, you have to remember to name them carefully so you don't use the same name for unrelated values - sort of like back in the days of BASIC where all variables were global. Its very easy to use a global variable in 2 places with a generic name, like "temperature" or "i" or "j" which are actually different quantities, and these errors can be hard to track down if you have a few hundred lines of code...... C++ was an attempt to tame C a bit to make it possible to write reliable code many thousands or hundred of thousand statememts long, so a lot of what you read relates to this. Generally speaking, professional coders will do any number of things to avoid global data because it is so hard to find problems because the compiler is not able to help you since the variable is supposed to accessible from anywhere. Global variables are actually quite efficient, because the compiler always knows where they are in memory. Its the programmer that has to keep where it is in mind at all times! As someone who has supported some very old C code littered with global variables, I can attest to the debugging nightmares. But if your programs are relatively short, there's nothing wrong with using global variables. Just don't tell anyone I said that.
Nicely put, Ian, and I won't make you wash your mouth out with soap either! I use the occasional global variable but it's a considered decision whether there is a better way. I'll cover more of this topic in a future video.
This is a lot of confusing information when you simply are calling "intOne" twice then calling "result" which does increment with the function... Your videos are great but look like they are design to drag your feet on empty statements.
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
The reference "points" to a memory address, but the compiler then does a lot of hard work for you that you have to do if you use a "real" pointer. That's why we should use By Reference where we can. It's a C++ enhancement.
It simplifies things and makes them easier. If you took a pointer you would have to check if it was null. Then you would have to worry about pointer ownership. Does the caller own the pointer or the called function? Who is responsible for deallocating the object? Also it probably allows the compiler to do various kinds of checks for correct code at compile time and maybe allow the compiler to optimize better.
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'm glad I'm inspiring you towards a better coding ethos!
Looking forward to the “pointer” video and how they contrast with pass by reference.
Yes, it will be interesting. But remember that C++ makes it easier to pass parameters using references; pointers are C old school! Sometimes, however, needs must.
@@RalphBacon I've seen C old school pointers in the STM32 line HAL. It drove me crazy figuring out what was going on until I realized they were using addresses & pointers. I'm looking forward to the video on pointers also.
I’ve seen pointers being used when looking at various programs in the libraries. So far I haven’t encountered a need to use anything other than pass by value and pass by reference. So I always wondered under what circumstances I’d need pointers instead. When I use pass by reference I find I’m more often doing it to keep the heap size down when passing long strings to functions rather than because I actually want the function to alter the value - usually I don’t want the function to alter the value - but I pass by reference anyway to keep heap size down. I wonder if there is a way that as I pass the parameter I can tell the function it is a constant (when in the main program it isn’t) and then pass by reference to keep heap size down, but be free from worries that the function will change the value - ie because it can’t, because to it the referenced value is a constant.
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.
Glad it was helpful!
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! ❤🎉
Awesome, thank you!
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.
Well said! Sounds like you are progressing your knowledge a lot!
@@RalphBacon it's my favorite language. I have add though Ralph so I'll code for a week straight then not code for weeks. So I'm always out of practice but I understand all the concepts. I need more work on library and class creation. It's gets boring making up bogus entity's to learn. I have a project I'm working on now though where I use vector math and dot products. I'm not one who copies code so I'll hammer away at something for 2 hours that I could've just copied and pasted and not understood more. I have a 32x32 led panel that I put together and I'm making as many of my own effects as possible that cycle in the background very dimly while the screen displays real data like appointments and date time. Hoping to add a cat locator eventually because the display is for my wife who works from home for the government. She floats around the province so there's no place to put her lol
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.
Nice of you to say so, Pajeet, stay tuned!
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…
Yes, I find it somewhat strange that the same symbol should be used to mean different things depending on context. No wonder everyone is confused.
Loving your series of videos. Your method of teaching is so clear and informative. Thank you.
You're welcome!
Ralph we need more videos like this!
Nice of you to say!
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...)
Hold your🐴horses, Byron, we haven't covered pointers yet. And I did say, quite distinctly, that references were not pointers. They could be viewed as aliases. At best, they were pointer-like (in the sense that there was no additional copy of a variable passed in). But let's wait for the pointers video... I don't have any pointer friends, by the way, they are too fickle.
@@RalphBacon I can't seem to find your pointers video. Is it up now?
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.
Yes, all parameters (variables) get pushed to the stack; objects go onto the heap usually.
Useful to remember that the Arduino String gets created on the Heap and turns it into Swiss Cheese as it is amended , making it difficult to find a large enough contiguous block of memory for other objects.
Thank you for concentrating on the why as much as the how.
My pleasure! Thanks for watching 🙂
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.
Well, maybe; By Reference is one of these new-fangled constructs that C++ allows for _our_ benefit, inasmuch that it abstracts away the complexity and danger of a pure C-style pointer. For example, you don't have to dereference a By Reference parameter. Nor can you suddenly assign it (to) another variable. But these points will be "addressed" (geddit?) when we do the pointers video. Probably.
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.
I'll add it to the list of things to show my viewers. Just remember that 'const' variables can only be set _once_ and thereafter they are fixed. The compiler can then compile more efficient code.
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.
Sounds like they were trying to be a bit _too_ clever!
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!
I can't remember if I did that pointers video or not; I may have baulked at it, given that pointers in C++ are generally frowned upon because they are usually not really required (except by ex-C programmers.
@@RalphBacon good to know.
I did do the video. But not yet released because I am not sure I could handle the queries!
@@RalphBaconturn off comments 😂. Promise I’ll point myself to Google for any follow up questions 😂.
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.
The use of a template means that the data type does not have to be known at compile time; it works it out at run time.
Pointers are quite straightforward and almost unnecessary in C++ programming (unlike C programming).
@@RalphBacon I added the 'const' in your PassByReference code: passIntByReference(const int &myInt); it's like the function says, "I need the reference location in memory to the variable, but I promise not to change it." Indeed running the modified code will give the compile time error: In function 'void passIntByReference(const int&)': PassByReference:27:21: error: assignment of read-only reference 'myint'. That was nice of put(). :-)
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 .
Indeed. For an integer or two, it's no big deal but if you are passing a large struct, for example, the memory can take a beating.
@@RalphBacon , ahhhh, penny dropped. now I see a practical use. would love a simple demo code that could demonstrate that advantage, in tems of memory use or data copy time. But not sure where to start in developing such a demo??
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!
This is CoolTerm by Roger Meier. It's freeware but if you find it useful a donation is the "right thing to do": freeware.the-meiers.org
Another good video, thanks. What debugger are you using please?
The serial monitor I'm using is CoolTerm, is freeware and written by Roger Meier
freeware.the-meiers.org/
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 😂😃
You can call this routine to tell you how much stack memory (SRAM) is left:
// Check stack space
void checkStack() {
unsigned long remainingStack = uxTaskGetStackHighWaterMark(NULL);
Serial.print("Free stack: ");
Serial.println(remainingStack);
}
Free memory is what is left after the heap and stack. Call every few minutes to see if it changes (normally does, sometimes significantly).
Although you _might_ be able to upload a full 32K of program memory, it would be a huge program. It's the variables you have to watch (SRAM/Stack), shown after every compile.
Another great vid at the right time. It cut down the code in my project immensely. Seems you’re on a roll. Thanks 👍🏾🤓
Great to hear!
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
Single-stepping, real time debugging is essential in some instances (like C# in a dot Net environment) but for ESP32/Arduino work you can always press the F12 key to see what is being invoked during programming too. Quite an eye-opener sometimes.
Not quite the same as actual debugging, but then again we're not trying to debug the framework (in dot Net terms we would "step over" that bit).
The new Arduino IDE 2.0.x supports single-stepping if your processor supports it. I showed it in one of my videos #180 th-cam.com/video/ArUzVt9z1ug/w-d-xo.html but it was very flaky at the time using a beta (barely) version of that IDE.
@@RalphBacon Yes I have my EP32 Debugger hardware on the way, not as simple as pushing a Button/Shortcut in VS, but it is what is. I'm learning something new everyday with MC's, now it's JTAG
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.
We'll be talking about references again when I release the References vs Pointers video!
Good explanation, as always.
Glad you think so!
Very well explained as usual, this cleared the fog!
Glad it was helpful!
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.
Returning pointers to variables or objects that have gone out of scope is a common programming issue. I fell foul of it just the other day, and could not understand why I could "see" the correct variable (a buffer) for just a fraction of a second, then just "null". Ho hum! (Hangs head in shame).
But the fact is, with robust programming practices there is nothing intrinsically wrong with C++. But it is not very forgiving (see first paragraph) and doesn't give any beginner-friendly messages ("Object you are referencing goes out of scope before it can be read") so we just have to be methodical and test more than the "happy path".
thank you for such an interesting explanation and examples.
Glad you enjoyed it!
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.
You will be an expert in no time at all then, Joey. 🎓
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 wonder how a literal (rvalue) was updated like that? On return from the function it suddenly had a different meaning... sorry, my brain just rebooted.
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.
Yes, they _do_ look too much alike. It's done deliberately to confuse us, I'm sure. More confusion lies ahead in the pointers video! 😬
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.
Are my viewers ready for the differentiation between stack and heap memory? I'll consider how best to address this so that beginners can understand it.
@@RalphBacon you will never know if you don't try ;-) But, when you explain it nicely, it will work. Don't underestimate the power of the pictures ;-)
Very well explained. Thanks!
Glad you enjoyed it!
serving up bits of info in a show is ok, but it would be more useful to explain global c pass by rules, with some examples of what would be if ...
Thanks for the feedback 👍
Nice information, thank you for sharing it :)
Glad it was helpful!
good points all
Glad you liked it!
I'm gonna start making all my variables global variables, just to trigger your angry faces 😂
The wrath of the bug-devil will descend upon you and cause a blight in your code forever and ever. 😡
One day before I die I hope I will get the hang of all this🙂
I just _know_ you had your fingers crossed when you wrote that!
Sorry Ralph, a bit like watching paint dry. LOL
Surely _much_ less interesting than that, John.
lol. hell yer this always catches me out :) cool video :)
Thanks for the visit, I hope it clarified things a bit for you.
@@RalphBacon just a matter of curiosity why is it that some folks dont like using global ?
Over my head, sorry.
No idea where this would come in to anything I work with.
That's a shame, Jorgo. But if you continue just Passing By Value, (which is the default way of doing things) your code will be fine. Just be aware that your function that you have called can never change the incoming variable unless it is Passed by Reference. Not a deal breaker for general hobbyist work.
tl;dw: difference is in memory usage.
and now i'll watch and confront ;p
And I edited this down to 15 minutes too! 😢 Oh, and if you just think it's just memory usage... well, double check your code that what you _think_ is happening _really is_ happening 😲
@@RalphBacon oh how i love to learn by prooving myself being wrong ;)
Actually i am not C/Arduino programmer (Perl here), however concept of "referrence" and difference between it and "intermediate variable" was clear for me on "this results in what" sense.
Never actually took as deep dive as you did here and was satisfied with code working as expected in any case :)
Thanks for your video, of course i watched it will the end (even without skipping sponsor message ;P)
You're a star, thanks for watching 🤩
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?
I too do and wonder the same thing.
No problem with global variables if you have a small program, like on a microcontroller. Once you have 100's of source files with squillions of lines of code then they're a problem - because it is hard to know what is going on.
Good question! I have answered this before but it's basically not a technical answer. Global variables work. They are not inefficient (although they do remain in memory forever).
But it's very sloppy coding. Certainly not Best Practice. Those variables can be accessed by _any_ function, not just the one(s) requiring them, now or in the future. The 'scope' of all variables needs to be controlled to avoid problems.
I'll do a more explanatory video on the whole topic one day soon.
Global variables become difficult to manage the larger your program becomes, because their scope is not "contained" to a function or set of functions. If you're writing small bits of Arduino code, then they are pretty harmless but if you start writing much larger programs, you have to remember to name them carefully so you don't use the same name for unrelated values - sort of like back in the days of BASIC where all variables were global. Its very easy to use a global variable in 2 places with a generic name, like "temperature" or "i" or "j" which are actually different quantities, and these errors can be hard to track down if you have a few hundred lines of code......
C++ was an attempt to tame C a bit to make it possible to write reliable code many thousands or hundred of thousand statememts long, so a lot of what you read relates to this. Generally speaking, professional coders will do any number of things to avoid global data because it is so hard to find problems because the compiler is not able to help you since the variable is supposed to accessible from anywhere.
Global variables are actually quite efficient, because the compiler always knows where they are in memory. Its the programmer that has to keep where it is in mind at all times!
As someone who has supported some very old C code littered with global variables, I can attest to the debugging nightmares. But if your programs are relatively short, there's nothing wrong with using global variables. Just don't tell anyone I said that.
Nicely put, Ian, and I won't make you wash your mouth out with soap either! I use the occasional global variable but it's a considered decision whether there is a better way. I'll cover more of this topic in a future video.
This is a lot of confusing information when you simply are calling "intOne" twice then calling "result" which does increment with the function... Your videos are great but look like they are design to drag your feet on empty statements.
Remember that my code is for demonstration purposes - it might not be particularly elegant (nor efficient) because I'm demonstrating a point.
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
The reference "points" to a memory address, but the compiler then does a lot of hard work for you that you have to do if you use a "real" pointer. That's why we should use By Reference where we can. It's a C++ enhancement.
It simplifies things and makes them easier. If you took a pointer you would have to check if it was null. Then you would have to worry about pointer ownership. Does the caller own the pointer or the called function? Who is responsible for deallocating the object? Also it probably allows the compiler to do various kinds of checks for correct code at compile time and maybe allow the compiler to optimize better.