I couldn't understand "It doesn't live on the stack nor heap but in the executable" because from what I have understood, When the program is executed it will be loaded to the stack. Maybe I'm missing something and hope I can find it. But I could understand how static keyword works from a high level perspective. Very neatly explained as always. Thank you.
Cheers! Maybe this link will be useful for understanding the different sections of an executable object file (web.archive.org/web/20170829060314/www.inf.udec.cl/~leo/teoX.pdf)
@@MikeShah hi mike, thanks for the great course. keep it up. I could not find the pdf form the link above. Do you have a direct link? I was wondering about the same topic.
Hallo Mike, I have so loved the topic. Great pictorial explanation ! But i did not get why the s_variable didnt increment when you remove the static qualifier. what do you mean by the variable static is save in the Binary? Looking forward for your explanation.
So a static s_thing is basically a confined global_thing. It exists from start to end of the program and is effectively handled by reference rather than a value copy, but it is only accessible by the local scope where it was declared (whether the scope is a simple block{}, function definition, class, or compilation unit). I don't fully understand the implications for linking behavior, although some experimenting may clarify it. If starting with main.cpp func.hpp func.cpp someother.cpp and func() has a "static s_variable" in its definition, will calling func() in both main.cpp and in someother.cpp access the same s_variable memory address? In otherwords will s_variable actually be created in func.o so a call from any number of other compilation units will access the same instance of s_variable? Then I get to the question of a header defined function or class containing static s_var2, will that cause multiple unassociated instances of s_var2 if the header is included in multiple compilation units?
Correct, static is a global variable with scope. Linking behavior -- for static symbols they are local to the module so are not overridden. Header defined varaibles that are static need initialized, thus why you do so in the .cpp file for static member variables in a struct/class.
Hum , watched the video again and have a flair of what is happening. what would happen if declare const, which means you can not reassign a value to it as you did in main. What if declared glabally? we were thought at school that static member variable is shared between the objects of the same class
If you make it const then you will not longer be able to change the value, same rule would apply. Making a static variable 'global' , or otherwise creating it outside of the scope, actually has the effect of making the variable only available within that source file (i.e. roughly speaking a translation unit). You are also correct that a static variable is shared amongst multiple instances of a class--because the memory is 'global' or otherwise the memory reserved int the binary is 'static' (or otherwise stored in one place).
Great discussion on the static keyword but I'm curious as to what happens under the hood when the ` static int x = 0 ` is executed each time. Does the compiler throw out initializations after the first instantiation? This is in reference to my comment on the Singleton design pattern. I think ultimately the take home point is that now matter how many times a static variable is instantiated, only the first is concrete.
It may be worth taking a look at the generated assembly: godbolt.org/z/x138soeo3 In this example you can see the variable has some reserved memory from the start of the application and the value is already set. Then calls later on access that reserved memory. Let me know if that helps clear things up.
@@robertstrickland9722 Just think of static as variables stored inside the binary. So there will be the initial value (or at least a place in memory for that value to be stored). It's worth also seeing what happens with a pointer. Here's another example godbolt.org/z/6oc91bseY . You will see in the assembly a 'guard' that essentially prevents the value from being initialized twice. There's a more detailed writeup here that may or may not be at the appropriate level -- manishearth.github.io/blog/2015/06/26/adventures-in-systems-programming-c-plus-plus-local-statics/ . Compiling a single threaded program with '-fno-threadsafe-statics' may also change the assembly in interesting ways as well!
@@MikeShah Do you do Discord mentoring?? haha I have a Singleton logger similar to this video and have it working but want to optimize it. When I put some of the generic code into the assembly analyzer it is a bit overwhelming.
![Dynamic Memory allocation with new and delete (and delete[]) | Modern Cpp Series Ep. 25](/img/n.gif)
Absolutely brilliant! The entire series is so well made!
Cheers!
I wish I had a professor like you in Uni. Would you please include the use of "placement new" in some episode? Thanks
That's on the todo list :) Thank you for the kind words!
Could you do a course on the contents of an executable and also how the executable is executed by the os ?
Will add it to the wishlist
I couldn't understand "It doesn't live on the stack nor heap but in the executable" because from what I have understood, When the program is executed it will be loaded to the stack. Maybe I'm missing something and hope I can find it.
But I could understand how static keyword works from a high level perspective. Very neatly explained as always. Thank you.
Cheers! Maybe this link will be useful for understanding the different sections of an executable object file (web.archive.org/web/20170829060314/www.inf.udec.cl/~leo/teoX.pdf)
@@MikeShah Thank you. That helped. I wasn't aware of the code and data segment.
@@MikeShah hi mike, thanks for the great course. keep it up.
I could not find the pdf form the link above. Do you have a direct link? I was wondering about the same topic.
@@derdere7803 Cheers! Link has an extra parenthesis -- try: web.archive.org/web/20170829060314/www.inf.udec.cl/~leo/teoX.pdf
@@MikeShah that worked, thanks again.
Hallo Mike, I have so loved the topic. Great pictorial explanation !
But i did not get why the s_variable didnt increment when you remove the static qualifier.
what do you mean by the variable static is save in the Binary?
Looking forward for your explanation.
So a static s_thing is basically a confined global_thing. It exists from start to end of the program and is effectively handled by reference rather than a value copy, but it is only accessible by the local scope where it was declared (whether the scope is a simple block{}, function definition, class, or compilation unit).
I don't fully understand the implications for linking behavior, although some experimenting may clarify it. If starting with main.cpp func.hpp func.cpp someother.cpp and func() has a "static s_variable" in its definition, will calling func() in both main.cpp and in someother.cpp access the same s_variable memory address? In otherwords will s_variable actually be created in func.o so a call from any number of other compilation units will access the same instance of s_variable?
Then I get to the question of a header defined function or class containing static s_var2, will that cause multiple unassociated instances of s_var2 if the header is included in multiple compilation units?
Correct, static is a global variable with scope.
Linking behavior -- for static symbols they are local to the module so are not overridden.
Header defined varaibles that are static need initialized, thus why you do so in the .cpp file for static member variables in a struct/class.
Hum , watched the video again and have a flair of what is happening.
what would happen if declare const, which means you can not reassign a value to it as you did in main.
What if declared glabally?
we were thought at school that static member variable is shared between the objects of the same class
If you make it const then you will not longer be able to change the value, same rule would apply. Making a static variable 'global' , or otherwise creating it outside of the scope, actually has the effect of making the variable only available within that source file (i.e. roughly speaking a translation unit).
You are also correct that a static variable is shared amongst multiple instances of a class--because the memory is 'global' or otherwise the memory reserved int the binary is 'static' (or otherwise stored in one place).
Great discussion on the static keyword but I'm curious as to what happens under the hood when the ` static int x = 0 ` is executed each time. Does the compiler throw out initializations after the first instantiation? This is in reference to my comment on the Singleton design pattern. I think ultimately the take home point is that now matter how many times a static variable is instantiated, only the first is concrete.
It may be worth taking a look at the generated assembly: godbolt.org/z/x138soeo3 In this example you can see the variable has some reserved memory from the start of the application and the value is already set. Then calls later on access that reserved memory. Let me know if that helps clear things up.
@@MikeShah Kind of but mostly because I"m not familiar with x86 assembly ha
@@robertstrickland9722 Just think of static as variables stored inside the binary. So there will be the initial value (or at least a place in memory for that value to be stored). It's worth also seeing what happens with a pointer. Here's another example godbolt.org/z/6oc91bseY . You will see in the assembly a 'guard' that essentially prevents the value from being initialized twice.
There's a more detailed writeup here that may or may not be at the appropriate level -- manishearth.github.io/blog/2015/06/26/adventures-in-systems-programming-c-plus-plus-local-statics/ . Compiling a single threaded program with '-fno-threadsafe-statics' may also change the assembly in interesting ways as well!
@@MikeShah Do you do Discord mentoring?? haha I have a Singleton logger similar to this video and have it working but want to optimize it. When I put some of the generic code into the assembly analyzer it is a bit overwhelming.
@@robertstrickland9722 I'm considering a Discord channel if the TH-cam channel grows beyond what I can answer myself here :)
Mike, do plan on teaching assembly?
Yes! Eventually there will be a series. Will be a bit in the future, but a series or a crash course at the least is being planned.
A series will be the best.
That would be great