That is a good point. Probably there is a linter that can help here too.

To be fair, I thought I know everything about this topic when I started preparing the video and it still took a long time to figure out all the intricate details 😅 I guess what I’m trying to say here is that I think I know how you feel 😅

Well, I deliberately don’t talk about every feature that exists in C++. I’ve never had a situation in my life when I had to use extern, apart from maybe language bindings. That is why it is not here at all. As for windows, thanks for the suggestion, I’m not a windows expert. But then again, I’m covering mostly things from the standard here.

I sure try to. I think it is very important when teaching anything. So please keep it coming!

Yeah, I hear what you’re saying. I think about it a bit differently though. Backwards compatibility is a feature of a language and influences the design of the language as a whole. It does mean that some features will become confusing but it is exactly this that is one of the reasons C++ is so popular. I for one am happy that there are new features added into the language, they make C++ a much more pleasant language to use. That being said, you’re not alone in your sentiment. Which, the way I see it, is the reason for existence of Rust, cppfront and Carbon languages.

Yeah, both are valid use-cases, although I would still say that these use-cases are a bit fringe ones. For case 1. you say yourself that we could make the local_v optional and superficially, I think I would prefer this solution as it indicates the intent of local_v being, well, an optional value. When reading such code I will have less things to think about. As for case 2. I would probably wrap such a call into a class with a static variable so that things are contained within that class. That is if I absolutely cannot avoid such a situation and make the changes local instead. Hope it makes sense. Or did I get it wrong? If you'd like to chat more about it, can I please ask you to write up a small example on godbolt.org and paste a link here? This way we can communicate directly in code without typing out code in youtube comments 😅

Thanks for all these questions. All of these suggestions come from the assumption that we use pure C++. When we have to guarantee interoperability with C things will be different. As for unity I won’t be able to tell as i don’t have enough experience with it.

Well, then I guess that’s exactly the point of the video, there is very little reason to do so if we are using unnamed namespaces rigorously.

@@CodeForYourself I don't understand you reasoning. If I want to force the compiler to make a compile time constant, I will need to use static/inline constexpr. Constexpr alone is not enough

@@CodeForYourself I think inside namspaces inline constexpr makes sense. Inside functions static constexpr makes sense.

@@xBiggs well, I think your statements are a bit too general. If you mark your variable as constexpr in an unnamed namespace it will be a compile-time constant, for example. So in this situation, constexpr is enough. Basically, whenever you are creating a constexpr variable at namespace scope it *should* be created at compile time. As for "inside functions" if you *need* a static variable there, i.e., the one that lives beyond your function, then sure, use static for this. But in most cases, you're better off with a constant at a namespace scope. Or am I misunderstanding what you're saying? Please feel free to provide an example on godbolt.org to illustrate what you mean if I misunderstand.

@@CodeForYourself Marking an automatic variable as constexpr does not guarantee that it will be computed at compile time. Marking it static constexpr will guarantee compile time computation. You could choose to do this at file or namespace scope (without redundant static), but then that variable would have increased visibility. Many constants are only used in the context of one operation so the increased visibility does not make sense and pollutes the namespace. Static constexpr does not make sense at file/namespace scope because it is redundant as you said. Inline constexpr is desired here for ODR purposes

These are all valid points and I agree that the statement is a bit controversial. There is probably no one solution that fits everyone. If you do need to call your code from C you will be optimizing different things for sure. But this is not who this video here targets. As for the performance concerns, the way you describe using static locally seems to be very similar to just using a global. My preference would be still to avoid globals. We could pass this vector from your example as a parameter to a function and change it there, which in my opinion is already a bit better as it shows the intent slightly better. I guess my main problem with the local static is that if we agree to allow such global objects hidden away into functions we make it less clear what happens on the caller side. In my experience this becomes hard to maintain over time and keep clear from bugs. But then again, we are talking about personal experiences here. The aim of this talk is to give a “good enough” guidance to the beginners. I am confident that most of the things to be done can be done without static (outside classes). Once we get to squeezing the last possible performance out of the program there are sometimes tricks we have to employ. But these problems occur at a much later stage when people usually have much more knowledge baggage to tackle them.

@@CodeForYourself I see your point, just not agree for my use cases where I find these much better 🙂 > We could pass this vector from your example as a parameter to a function and change it there + > I guess my main problem with the local static is that if we agree to allow such global objects hidden away into functions we make it less clear what happens on the caller side. In my experience this becomes hard to maintain over time and keep clear from bugs I actually think this approach of sending in a vector is more bad for bugs! Why? You say the static local variable is like a global one. In storage yes - but in scope no! Also if you think about it: Making API such a way that the caller provides the vector to use makes more possible mistakes and is less self-contained, localized code. Also ownership becomes not clear and needs to be documented. I am not saying its a hugely bad alternative solution, but it has two issues: Less locality of the code (thus less good maintenance - as for good maintenance you want things as local as possible) and the other issue is that this solution takes a bigger refactor to the codebase - also possibly breaking binary compatibility of your library if this is a library. The solution I advise has none of those issues and you might argue that when someone first see this "pattern", that is new to them, but I used to comment over these kind of static (thread)locals with // JHapak's pattern... That makes people ask either me or the project docs about what it is and its very easy to get the hang of this. > Once we get to squeezing the last possible performance out of the program there are sometimes tricks we have to employ. Things is that honestly this is not "last possible performance" like a thin margin, but I know cases when just this sped up an application 300x in certain algorithms related to parsing little strings. So much so that I really would advise teachers to literally teach this lesser known thing as pattern in programming. I literally prefer this solution to all the custom allocator style solutions and it is very handy to know about this pattern. Also worth mentioning that maybe it would be nice to have compiler / language support for this pattern - beause currently its hard to abstract this kind of working out (like "JPTR_string" wrapper around string) without using macros. That is I mean "by using a separate local or each call location" - because shared one is easy to do. I wish there would be something in the language to support this construction more, because using it very often. > But these problems occur at a much later stage when people usually have much more knowledge baggage to tackle them. First I wanted to argue with the "later stage" by saying that in my experience its very hard to first just write the code and only AFTER optimize it (will lead to very bad performance because architecture is not optimization friendly) - but I see that you mean later as in someone life / experience with C++. But I honestly think its not that hard to know what static is useful for this situation and this situation also teaches well what static means in that local scope use case well. Also if you think about it: using C++ is already a premature optimization (a very good one - I believe its very huge misconception to think optimizing on the go is bad) and thus for stuff that do not need these kind of things maybe the language was a bad choice anyways so I expect people to know what this static means in those circumstances. It is happening a lot in our codes because I choose not to abstract it behind some macro. Then a newcomer would come and if they learned from someone this is not to be used they would all the time create performance regressions (or code review work) which is not good.

@@u9vata I don't fully agree with your suggestions, but I think it is hard to argue about the particulars here. You clearly have some good experience using static in the way you describe, while I have experience nearing the opposite. Considering how versatile C++ is, probably both arguments hold, depending on the concrete design. I definitely don't feel comfortable telling that "not using static is the only way to go", but it *is* the way I had very good experience with over my decade+ long professional usage of C++, in safety critical systems among others, so I do feel comfortable recommending it as a guiding principle. One thing I already mentioned in another discussion under this video is that static data makes things much harder to test, especially if we want to run tests in parallel. But this is just one data point. I feel that if we stay at very general level we will get stuck in a local maximum of our conversation along the lines of "my experience is" and I don't believe that this is a good place to start a meaningful conversation from. As an alternative, we could find a concrete example and share it on godbolt.org, quick-bench.com, and cppinsights.io digging into particulars and figuring out why we see a certain behavior. Thoughts?

@@CodeForYourself I am not sure if microbenchmarks helps in this case, just generally found that saying "inline" usually is more often not inlined than inlined. Maybe this you can test with some godbolt scenarios. For the others there is literally no need for godbolt - for the static in local scope the langauge definition describes already what I want so is realiable. In case of the static inline functions outside classes being more easily inlined I think that is a compiler hint currently and I just only hope they keep it that way. In any ways. I suggest writing inline asdf() {....something } in various cases and see how many times it is indeed inlined - you will likely get surprised how many times its not inlined and when you do perf that is what you want. The static linkage helps here because the compiler knows this function can never be called outside of the current compilation unit so it more easily inlines them without generating function code. I also use this kind of static inline codes in header-only libraries. There was actually even a case (I can't recall what was the code) where it was the only solution or goto - ended up actually writing goto as it was more performant (less instruction cache clutter). I think for the case when we talk about static functions outside classes - that is useful because its how it turned out to be, but if I would design my language I would likely not do it this way. But for the static keyword in local scope in function bodies its a good pattern (maybe a bad name for the keyword one can argue though).

@@u9vata I fully agree that inline does not really control inlining much. I also agree with you that putting functions in such a place where the compiler can reason about them easier makes its work of optimizing stuff away easier. So, static with its superpower to make functions have internal linkage, helps for sure. That being said, I've had pretty good milage out of the link time optimization (LTO), which partially mitigates the issue. I also agree that you might get some performance benefits of putting static within functions, but I really dislike this pattern from readability and testability perspective, so I would only do it if I need to for performance and even then I would think and measure twice. Even in the core guidelines, they explicitly mention the case you are talking about in not too favorable terms: isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cp1-assume-that-your-code-will-run-as-part-of-a-multi-threaded-program, also here: isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cp2-avoid-data-races. In the end of the day, most of the code is not living on the critical path, so I'd argue that readability is more important for the vast majority of the code. 🤷

I don't fully understand your setup. Could you maybe elaborate?

I’m not sure it is guaranteed that a static variable will be initialized at compile time. Although I’m not 100% sure.

@@CodeForYourself I didn't say they would. Nothing of the sort. I am responding to your claim that there are no justifiable uses of static variables at the function level in modern C++. There absolutely are. One example: Lookup tables or similar "static" data that must be calculated with non-constexpr functions. It simply isn't an option to calculate them at compile-time. They cannot be constexpr. But they are static data and should only be calculated once. Hence, static storage initialized at runtime. A related example: Lookup tables that are larger than you want to store in your binary. It is quite common (in fact, the whole point) to pre-compute lookup tables to trade performance for memory usage. Lookup tables are generally large in-memory but are computed from "small" formulas. 'constexpr all the things' doesn't mean everything that can be computed at compile-time _should_be_. Or, maybe it does... but that's wrong.

Yeah, this recommendation is for C++ only. I’m not a huge expert on C, so I can’t give a confident advice there

That should be ok. What I meant is “don’t *write* inline in the source file”. If it gets there through a header file it’s ok. Does this make sense?

Sorry, I don’t get what you mean. Care to elaborate?

​@@CodeForYourselferrno is global not const variable(ish) that is set by many functions like execve (ish): errno is not actually variable on glibc on linux: # define errno (*__errno_location ())

@@RandomGeometryDashStuff ok sure, but what of it? What is the statement that you are making here?

@@RandomGeometryDashStuff I don't think C++ people use errno like C people do

​@@xBiggshow else to get which error happened in recv (example)?

Ok, I see your point. The reason unnamed namespace is more powerful is that it also works with classes. If you define a class in an unnamed namespace it will also have internal linkage. So it is simply a more universal way of forcing internal linkage on stuff. As for “static member in functions” I don’t really know what you mean. If you mean marking a local object in a function as static then I think I did give some reasoning. It mostly gets used to return such a value out of a function, which basically makes it a kind of a global variable.

@@CodeForYourself having static variables can be used for many thing - we use it extensively for quasi-global configurations that can change at runtime. There needs to be a way to access them, some of them might never be used - what other way is there than quasi-global variable via a function? None that is anywhere close to in terms of ease-of-use, safety, or performance. And global namespace also being able to define classes - then we should use Goto instead of For-loops.

@@ABaumstumpf I know that sometimes it makes sense to store configurations as a form of Mayer’s singleton, i.e., returning a static object from a function. It does provide a benefit of initializing the object on demand exactly once. However in my experience, I prefer passing the configurations around as a const ref instead if this makes any sense. As for your comment about goto statements - I don’t understand what you mean. What is it that you’re saying here?

@@CodeForYourself "I prefer passing the configurations around as a const ref instead if this makes any sense." That procludes you from any changes or reloading of the config outside from the single-point of truth and limits the ability to replicated or swap the config - or you have to deal with lifetimes your self again. "As for your comment about goto statements - I don’t understand what you mean. What is it that you’re saying here?" On the question of why we should use anonymous namespaces over the more concise static you said cause it is more powerful - by that logic you must also advocate for the more powerful goto over simple loops.

@@ABaumstumpf I disagree with both statements here. With the configs, I can still make changes, I just have to be more explicit as to where and when they are made. In my experience this is less error prone. If you have them as mutable quasi global objects you give away control over them and also make your code much harder to test. As for the goto statement, that is your logic not mine. Goto statements are very error prone, that’s why we don’t use them anymore. I also fail to see how static is more concise. If you have two or more static variables you already have to do more typing than if you just put things in an unnamed namespace. And sometimes structs and classes should have internal linkage, what would you suggest to do with those other then put them into an unnamed namespace?