C++ Club - 168. Safety, "C/C++", reflection, include order, Bjarne Stroustrup's quotes

Episode Date: December 27, 2023

With Gianluca Delfino, Frances Buontempo, Vladimír Arnošt, Dmitry Kuzminov and other colleagues.Notes: https://cppclub.uk/meetings/2023/168/Video: https://youtu.be/spKvxc2R7nc

Hi everyone, welcome to C++ Club. This is meeting 168 and today is the 14th of December 2023. This will be the last meeting of this year. And we'll start with some feedback. Actually, two kinds of it. The feedback is about our meeting 166, where we've discussed Herbsatter's update on Cpp2. And the first comment is by Roy Barkan, who tries to clarify the code snippet we discussed, if you remember, it was this one where there was an assignment to an unused underscore variable at the end and we weren't sure what was the purpose of it. At least I wasn't. So Roy explains, quote, I think Herb's point is that the combination of, first, his CPP2 feature of automatically std move, the last use of each variable, together with 2,

the fact that r values can't be passed to functions that take mutable reference, and C Cpp2 inout or out parameters. That all equals means that a mutable reference and inout or out parameters will act as no discard and will have to be manually discarded via the assignment to underscore. I guess Herb likes it because he likes no discard, and he is happy that he got it for free as a consequence of one and two above." So yeah, I think that more or less clarifies it and sheds the light on the original intention of which I wasn't sure at the time of discussion. And then there is the second comment by Walter Svendal.

Quote. It's honestly pretty infuriating how often this group completely misunderstands the articles they read. Like how for about 5 minutes in discussing CppFront's explicit data flow, they speculate the purpose of discarding X has something to do with optimizations. And then when they finally continue reading, they realize it's just about data flow, then misread the article again and somehow hallucinate that the discard statement must be modifying the behavior of the previous function call.

This has happened many times in past videos. Does the presenter read the articles they talk about beforehand? It seems like something they should review beforehand instead of just guessing without reading during their meetup. Wow, harsh. What can I say? I'm really sorry. I'll make sure to understand 100% of everything I read from now on. I mean, you know, I understand where it's coming from. And I

think I, you know, we welcome corrections in the comments, you know, especially the many times we get things wrong. We obviously never try to purposely misrepresent things and certainly not everybody reads all the articles before because that's probably not also the purpose of the call the purpose of the call is just to have a chat between friends and go through the latest things, maybe understand them better together. But certainly it's not to teach or properly explain things. So I don't know, maybe we should have made that more clear. Maybe sometimes we talk about things

we barely understand. Most of the times could also be the case. Do continue, I think, correct us things we barely understand most of the times could also be the case um do continue i think correct us in the comments i think uh we will uh look at those we will uh correct whenever we said something wrong you know uh straight up the record we are sorry that somebody had to be infuriated you know it just doesn't have to get to that. You know, it's a friendly conversation. So please join us in the conversation. You know, point out when we're wrong.

We will admit it. Very well put. Thank you. I can confirm that this podcast is not the final truth in C++ and we are just chatting and discussing things and we are often wrong. So take everything we say with a bucket of salt. Or a small grain of salt. I don't know which one is the correct way of saying that. Because you have to take it with a grain of salt, it means take it with very little amounts. So if somebody wants to correct us in the comments, which one is the correct way of saying that? If it's with a lot of salt or

with a small amount of salt. Next is NUC slash C++ is bad actually. White paper has dropped by the US government. Oh no! Yep, it was published by USA Cyber Security and Infrastructure Security Agency. CISA maybe? It looks pretty serious with a nice title page and everything, lots of intimidating agency names. I haven't read it in full. I only skimmed it. But yeah, it's the usual pitch for abandoning C slash C++ and moving towards memory-safe languages because they provide more guarantees against exploits.

Again, I would say we need a better PR department. Quote, Memory safety vulnerabilities are the most prevalent type of disclosed software vulnerability. They are a class of well-known and common coding errors that malicious actors routinely exploit. These vulnerabilities represent a major problem for the software industry as they cause manufacturers to continually release security updates and their customers to continually patch." So they want to urge software manufacturers to prioritize using memory-safe languages in their products.

And presumably abandon C and C++. Funnily enough, they don't use C slash C++ in this document. The author probably thought, oh, Piano doesn't like C slash C++. I know. I'll use C and C++ everywhere instead. But these two are, like, always together in this paper, so it's pretty much the same thing. Also I noticed that there were no examples of other memory-unsafe languages. So it's all about C and C++ then? Why not say so? There is another quote from the document. The paragraph was safer language subsets and the quote goes like this. The C++ community has been contemplating the balance between backwards compatibility, memory safety defaults and other priorities for

the base language. There are multiple targeted efforts to make C and C++ less vulnerable for existing code bases and products. For example, Apple has modified the C compiler toolchain used in the iBoot system to mitigate memory and type safety issues. Microsoft has developed CheckedC that adds static and dynamic checking to C to detect or prevent common programming errors such as buffer overruns and out-of-bounds memory accesses. There are more general efforts to improve C++ memory safety for existing code, including efforts like Carbon." So as you can see, they bundle all kinds of stuff together. They start with C++ community and then suddenly switch to C language for some reason.

Because Apple and Microsoft's efforts are targeted at C and the runtime, which works for both. And Carbon is definitely not about improving C++. So yeah, there were two discussions on Reddit that I saw. The first one is more balanced and the second one is more rants, pretty much. That was my impression. Were the rants against the message from CISA or were the are ads against the current state of C++? Against C slash C++. And as usual in these discussions, for Rust.

So some quotes from the first one. Well, they're not wrong to point the finger at C slash C++. And the other one, as Trois Troupes said, C slash C++. And the other one, as Stroustrup said, C slash C++ is a mythical language. I know C and C++, and you write those quite different. One quote from the second discussion. They've been saying this for almost 10 years now. Most security issues are not the result of malevolence, they're the result of human error. I've seen some of the code that contractors have delivered. A lot of it was appallingly bad. It's cheaper and safer for them to get people off of C slash C++ than it is for them to try to clean up and secure dangerously

bad code. End quote. Yeah, this checks out like, example, Chromium codebase is starting to migrate some parts of it to Rust, which I guess is easier than to rewrite the existing C-like C++ code in normal C++ and maybe shock and horror use smart pointers. And not use ShareP share pointer everywhere also. That's also true, yeah. But there was a feedback on feedback. So basically, how should I put it? CISA issued this paper and then there was the comments section on the website

where everyone could comment. An anonymous comment appeared with the attachment of a response by the prominent C++ committee members to this white paper. And some people took some sort of offense that the comment was anonymous, and the reply document pretty much repeated everything that Bjarne was saying, that memory safety is not the only type of safety, that there are type safety and others. And the committee is working on it, has been working on it for a long time. There is this new idea of profiles and everything. So it kind of tries to explain the C++ side of things. And the feedback on this document had been... I don't know, it's just bananas.

Obviously the Rust people took it and ran with it. I mean, I don't blame them. This kind of message just encourages more and more people to just say, okay, why should I learn a lot of things in C++, which is complicated if the industry is shifting and, I mean, you know, C++ could die a death of a thousand

cats, you know, because of this kind of statements and well, partly it's the C++ fault, you know, maybe, you know, the C++ somehow language should have changed, should have been fixed, but some of it is just perception, I would say, you know. So it's hard to say if this is actually going to have a dramatic effect on the future of the language. But it will certainly make the news and inflames hearts on both sides, which is good, but mostly

bad. I agree. This is one of those thousand cuts, like you said. And it continues to erode people's trust in C++ undeservedly, I would say. The comment with the attachment says, quote, memory safety is a very small part of security. Different application domains have different safety requirements. C++ is a mature language that has proven viable in most application areas and countries.

C slash C++ is not a language, but a style of use. Complete and verified type and resource safety is possible in C++. Improved safety for various safety requirements is a long-standing tradition in C++. Complete type safety in the absence of resource leaks can be had in C++. Changing languages at a large scale is fearfully expensive. And the document itself basically expands on that. So someone, some guy called Andrew Lily Brinker says on Mastodon lol a group of unnamed C++ senior members with decades of experience in ISO C++ filed a response to the federal RFI on open source software, and it is ridiculous. By the way, he includes in every toot of his the hashtags Rust and Rustlang.

They don't name themselves, he says. It's unclear if this is an official ISO C++ response. The response tries to muddy what safety means, argues a strawman about Rust having vulnerabilities too, suggests profiles for C++ should fix everything anyway, hints that C++ critics are actually just talking about old C++. In the same breath they argue that C++ is great because it's always stable so old code sticks around forever, and that really you should give C++ more money. Who's giving C++ money?

I don't know. Certainly not the US government, to my knowledge. And the committee doesn't get any money anyway. Yeah, anyway, the authors of the documents are Howard Hinand, Roger Orr, Bjarne Strøstrup, David van der Waarde, and Michael Wong. He continues his rant, and basically his friends in the Rust community agree with him. Too much drama. He again smashes together C and C++ like they usually do. Sorry, go on. No, I wanted to say, certainly all this drama is probably what comes up first in the Twitter

sphere or whatever it is called nowadays. And all the reasonable discussion between what we call the RAS people and the C++ people, which some of the time overlap, it's a lot more sane and productive. So I think we both have to learn a lot from each other. RAS certainly has things to teach C++. And have all these flags up with all the hashtags and name calling really doesn't help. Keep in mind that these are people who do not use C++.

And now I wanted to show you some of the toots by people who do use C++. Doug Greger says, If you sprinkle in a little bit of wishful thinking about future static analysis tools, this is exactly the message trust is spreading and is getting repeated by many other people on the C++ talk circuit. It's wrong, but it's also a very hard thing to confront when you've made a huge investment in C++, especially if it's a personal investment." He's arguing that it's like a sunk cost fallacy.

My impression is that these people who are trashing this response and trashing Bjarne's talks about safety, they all want simple one-step solutions. One of those would be to migrate to another language. But simple one-step solutions rarely work in the world, especially for an established language like C++ with a huge codebase. I liked what others said. Peter Somerlad replied to Andrew Lili Brinker, quote, I would sign what was stated. The problem I perceive is developer education of good practices.

This won't go away by using a new language. And Daniela Engert replies, the last sentence in that document summarizes that quite well. For applications where safety or security issues are paramount, contemporary C++ continues to be an excellent choice. Using contemporary C++ ruled out all memory safety problems and more that I've been haunted by before embracing such design approaches 10 years ago. It's not the language, it's the mindset. Subverting safety in safe languages? Been there, done that. None was really safe. An extraordinary voice of reason that we have.

I am so happy that she's around. Indeed. She also says, I think there is way too much politics at play here and dishonesty. Nobody cares as long as funding gets diverted to their direction and pockets. Funding is nice as long as you can stay in the general and don't have to prove anything. A smear campaign directed at people who are not challenged by knowledge of realities helps.

If such campaigns are in full spin, people can become upset. And someone called Lester asks, Daniela, what's contemporary C++? They searched for the term and couldn't find it. Some say it's modern C++, but it's also not very clear. And she replies, glad you asked. Contemporary C++ is a term that I came up with to describe as succinctly as possible what I intended to convey to the audience in my keynote last year at CppCon.

It is deliberate to not have a precise definition. Contemporary implies change over time. That's the whole point. She continues, modern C++ was a thing, the shiny new features and design approach in the early 2000s. Nobody would call this modern anymore, despite some ideas still falling into the contemporary bucket. And then C++ with a completely new way of thinking, called postmodern by some. Some of that is still contemporary. Contemporary C++ is for the most part C++17 and beyond, plus all the good stuff from earlier versions of the C++ specification that have stood the test of time. If you develop in this easy-to-grasp part of C++, you are safe and can live a happy developer life." So yeah, this is the voice of reason.

And yeah, don't despair. And don't pay attention to rounds of people who don't really use C++. We should discard the drama and less drama and raise this kind of voices like Daniela. Reflection feedback is next. And I won't go through the entire thread, but it starts with this. Anyone find the proposed reflection syntax distracting? And the first reply is excellent. At this rate, I'll take poop emojis as the syntax.

Inject this feature into my veins now, please. End quote. I think I applauded that. Yeah, me too. Others don't have much of a problem with the unusual syntax of square brackets and colons. I'm sure there'll be some fancy ligature in some fonts soon. I wanted to show you this interesting development. There is a new library called ReflectCPP. Automatic field name extraction from structs is possible using standard compliant C++20 only.

No use of compiler-specific macros or any kind of annotations on your structs. There is a corresponding GitHub repository. This library seems to be pretty capable. There are examples of use. And the author says, I'm aware that libraries like Boost.pfr are able to extract field names from structs as well, but they use compiler-specific macros and therefore non-standard compliance C++ code. And someone asks, is there a short summary on how this works? And how this works is actually a brilliant idea. Most of the magic happens in here. The C++20 standard provides a function called std source location current function name,

which gives you the name of the current function you're in. If the current function is a template, you will also get the parameters passed to that template. The library then expresses your structs as an extern. If you then pass pointers to the field to the function containing source location current function name, the resulting function name will contain the name of the field. All you have to do is to retrieve it from the string.

I barely understand it, but this is something that spawned off the mind of Chris Jusiak last week or so. I saw his post, it was a Reddit post. I'm not sure who was the first, actually, because it was pretty much at the same time, and this library looks like it's been in development for some time. I think, well, I don't want to get it wrong, but I think in this post somewhere it does say that this was inspired by the other one. Okay.

Do you remember where that was? I have been in the original in the original post by Chris, that the same commenter commented, great, I'm going to update my library. And basically happened overnight. I see. That's interesting. So I really good one-two punch on this and on both sides and a pretty good result. This is an amazing, we could even call it discovery, a use of C++ feature in a completely unintended way, a new way. I still don't believe it.

I still don't believe it. And I'm afraid somebody's gonna wake me up and tell me this is not gonna work because... I don't know, but it is beautiful. You do have to be on C++20 to be honest, so not all of us are as lucky. But this is brilliant. This is a brilliant idea and kudos to everyone involved in the development of this. While, obviously, we're waiting for the proper reflection, hopefully. Going quickly through some of the articles. One was a compiler option hardening guide for C and C++. This is by the Open Source Security Foundation Best

Practices Working Group. This mentions C slash C++ or C and C++, but in a good way, because all those switches. We'll take that. Yeah, we'll take that. All those parameters work for both. This guide is pretty extensive. It's very long. And they explain all the options and say which compilers support that. These are GCC and Clang only. There's no MSVC. Fair enough, the arguments are completely different there.

It's very detailed, it includes sanitizer switches and all kinds of nice things. Definitely something to save as a reference. A new development from JetBrains. There is something called CLion Nova. It is a free early preview of a new version of CLion, which is currently a separate application, but they plan to merge it back into the legacy CLion when it's debugged. And the difference is that the C++ engine is different now. The first C++ engine, they say, was designed for AppCode, RIDE, for iOS and MacOS developers. Then CLion got a ClangD-based engine. So there were two engines. One is like Java-based IntelliJ platform and this new one based on ClangD. But now they're using the engine that's currently used in

ReSharper, C++, and Vrider. And what's different about it is that it runs separately as a separate process and communicates with the IDE. Not like IDE, it doesn't use it as a library, but talks to it as a separate process, which should help reliability, I guess. So I tried it. It's OK. I didn't do anything much with it, but it certainly feels pretty fast. From my experience, ReSharper C++ slows down Visual Studio quite a bit,

but that may not be the entire fault of ReSharper. Do you find ReSharper C++ to be useful? I've never something really... I have it installed at work in Visual Studio 2022. It provides lots of diagnostics. I'm not sure if it's more useful than the built-in diagnostics of Visual Studio. I don't know, my mind is split. I'm not sure. I know that previously I've used something called Visual Assist. If you remember, Visual Assist X was another plugin for Visual Studio, the older one. I think it was acquired by Embarcadero and built into C++ Builder. And Visual Assist X was blazing fast and very useful.

But granted, at that time, Visual Studio itself didn't have much of on-the-fly diagnostics, so that was very helpful. I don't know. I'm probably going to try Visual Studio without ReSharper and see if I feel any difference. Let me know. I am honestly interested. I have heard about it many times, but I actually never tried it. So there was this article, this post on Reddit, features to remove from C++. Quote, C++ is getting more and more complex. The C++ community keeps adding new features

based on its consensus. Let's remove C++ features based on Reddit consensus. In each comment, propose a C++ feature that you think should be banned in any new code. The usual culprits like explicit by default. And things like that cannot be removed from language. It's like vector... No, actually, vector bool is useful in some cases.

But yeah, there's a long thread, lots of runs. But some quotes... It depends. Sorry? Do they mean to remove the implementation of VectorBool that is currently a plague, or remove VectorBool entirely? I think they probably just mean change.

My take on it was prohibit these in new code that you write. So don't use V bool in your code. But some people obviously misunderstood and said explicit for everything and no discard and whatnot. Yeah, it wasn't in the spirit of the game. And some funny comments. This one. Everyone agrees that C++ is broken, but no one agrees precisely which parts need fixing,

which just goes to show that the language isn't broken at all. It just has a very wide user base with very diverse needs. One code as boondoggle is another code as bedrock. End quote. I like the word boondoggle. I never used it. Same. I'm the word boondoggle whenever you say I'm gonna start. But yeah, I mean, again, very, very good point. Very same point. Also, all the new coming dialects and languages

and carbon and CTP front, they all have a lot of mysticism, a lot of undefined features. and then a lot of people like to project whatever it is that they would like to see in those. So I am looking forward to version 1 of those implementations, and I'm going to be reading the angry comments, chewing popcorns whenever that happens. I'm sure not everybody is going to be happy anyway. Another comment says,

got to love how nearly everything suggested in the replies, say for std vector bool, is followed by a reply saying how that feature is actually useful sometimes. It's too late for C++ now. At this point everyone uses it in their own particular way and every obscure or weird feature has found its place for someone. And this is a winning comment. The only thing wrong with C++ is other users of C++. There is also this notion of Chesterton's fence, which is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood. And I think C++ is full of those. Chesterton's fence is all the way down. Hacker News discussed some Bjarne's quotes. Hacker News is often pretty harsh in their discussions, but this discussion is very positive and many posters liked quotes and followed them up with their own experience.

This quote, language design is a curious mixture of grand ideas and fiddly details. And another one, C++ is a language, not a religion. That's actually not a quote from the official Dianus website. But the poster says, I swear Stroustrup said this at the beginning of his computer science colloquium talk at Stanford around 1986. At the time, we grad students were all C programmers, and we were sure that C was the best language ever, at least better than Pascal,

which was the language Stanford used for teaching back then. So we all wanted to see this person who had the temerity to claim that he had improved C and who has the audacity to call it C++ of all things. A skilling auditorium was packed. When Strohstrub took the stage, a tense hush fell over the crowd. He said the above line fairly quietly, and everyone burst out laughing, breaking the tension. The rest of the talk was a pretty straightforward explanation of C++ 1.0, and I came away fairly impressed. Several years later, at another talk, I asked him to inscribe my copy of the C++ book with

that quote. He claimed not to remember it, but he inscribed the book per my request anyway. Then it is history. Yes. And someone replies, I disagree so, so strongly with this. C++ programmers are one of the most religious groups around, eclipsed only recently by the Rust community. Try telling a C++ programmer R-A-I-I is not a good idea,

I dare you, or smart pointers, or that the STL is mostly garbage. Trying to honestly have these conversations is typically an exercise in starting a religious flame war. And I'm like, what? And someone replies, I am a C++ programmer, and if you told me those things, I would just flip a buzzer bit on you and carry on coding. No religious claim is warranted.

Yeah, so this is just a futile attempt at trolling, but actually not a serious comment. This is a quote I liked, the problem with many professors is that their previous occupation was student. I'm sure we've all seen people like that. I want to just pipe up at this point, I've had my nose in some academic jobs on and off. And there are lots of people who've gone straight from being a student to doing a postdoc and then going on to be a professor. But one or two of them do manage to, like,

even if they've not worked in the industry, do manage to collaborate well. So there are exceptions to everything. But, yeah, if you just get stuck in one track through life whether that's academia or business then you're missing part of the bigger picture which is why this meet up and just chatting is nice to see different people's perspectives yeah keep your eyes open and don't just do flame wars and nonsense let's be nice to each other and help each other. Thank you. Yes.

Be excellent to each other. Nice tagline as well. And obviously this quote of Bjarne's, there are only two kinds of languages, the ones people complain about and the ones nobody uses. So we'll end this section on that. There was a Reddit thread, will C++ ever get a standard GUI or 2D graphics library? And the consensus was that it's not something you want in standard library and mostly people are against it i think i mean it's uh it's understandable that people are uh upset i i mean i wish there was a

magic answer that we could get somehow a kui interface because that's what people like. I mean, a lot of people learning a new language, they like seeing the window. They like pushing the button. I count myself as one of those. But I understand all those commenters saying that's probably not going to happen because they're unfortunately very good reasons. Yeah, I wouldn't count on it.

Well, there are many multi-platform libraries you could use. They just don't have to be part of the standard. And then we get into the packaging conversation. If we had a good packaging solution, then this would not be a problem. And yeah, I mean, all of this, you know, it's always good to talk about it. Sorry Gleb, you know, to interrupt. No, no, that's exactly what the discussion veers into,

build systems and package management. So you're completely right. And Vladimir, exactly. There are so many libraries, and they are so different that to come up with some new standard one that everyone is happy with is pretty much impossible at this point. But if you do manage to set up Conan or any other good packet manager, then as Vladimir says, it's perfectly reasonable. Just use that and bring up whatever flavor of GUI you want. A lot of people like iMGUI or iMGUI. I don't know how to pronounce it.

I have no idea. iMGUI? I don't know. But yeah, there are lots of those. Someone replies, considering we had to wait till C++23 to have string contains, we can hope for standard GUI at best for C++92. C++92 also has almost a retro feel to it. It almost goes all the way backwards to C++92. It's a wrap around. No. We overflow. Overflow, yes. This one I wanted to sort of ask you about. This is a post on Stack Overflow. C slash C++ include header file order. Which order should include files be specified?

Do the system files STL and boost go before or after the local include files? At some point, we used this scheme where the first include in the CPP was the interface file for that CPP. Then we had all the local files, then internal libraries, then BOOST, and then standard headers. So sort of in reverse general purpose order, so to speak. But then I ran a Google tool called include what you use, which tidies up and reshuffles headers.

And it appears that their default sorting is the other way around. So they start with the interface file, which is quoted, and then they go from most general to least general. So we start with standard library, then boost, and then your local libraries, and then the local files. I don't particularly care one way or another as long as it's consistent. And now that I'm using include what you use, it's sort of... I can't really do anything about it. But what do you think? I think it's most common to see the standard up top. Dmitry, go ahead. The first approach has common sense. So we minimize the dependencies, unusual dependencies. I saw a lot of mistakes just because a header file that didn't

include certain headers was working in certain contexts and didn't work in other contexts. So including std libraries the last is beneficial because we can find latent errors yeah i was going to say i i've i've worked contracted in so many different places and lots of people have lots of different opinions i've used include what you use as well it's really cool to me the important thing is if you were to randomize the order you included them in would you get some build errors so like we've just said if you haven't included things you actually need that will flush things out so when no one's looking mess with them a bit and see what happens because you can find problems that way i think that's more interesting. Good advice indeed. Headers and CPP files should be self-contained,

so they shouldn't depend on order of includes. I like anyway the tool include what you use. It's a good thing to recommend whatever comes out of it. If it works and builds, I'm very happy with it. And I do hope that modules eventually will render this conversation useless. Yes, yeah, yeah. And on top of that, a very good recommendation

is to sort all the includes within each part. So all std libraries should be sorted, all boosts and so on. I agree. As long as we can use a tool to do this. I think it does it. I think you can specify, ask, include what you used to sort. Great. So I think that's it. From the web, there's a funny quote for you. Name a book that made you cry. And reply was data structures and algorithms in Java. And this is an unbelievable new startup that I lucid dream startup it was in the fortune journal

and the title was lucid dream startup says engineers can write code in their sleep work may never be the same I don't want to talk about infinite loops sorry, that gives me nightmares. There's a whole discussion on Slashdot about it and people are generally pretty horrified at the idea. And I'm like, you're taking my sleep from my cold, dead hands. Coding in

my sleep. What next? Watching ads in my sleep what next watching ads in my sleep no I will I will postpone my worries about this whenever the actual implementation happens I I don't know is this flashy news or it it actually something concrete? It seems to me that maybe one day... I think someone at least managed to convince some venture capitalists to invest in their idea, which is impressive. That is impressive, but I think it was just convincing somebody. You can lie to somebody forever. That's some level 80 tech bro manipulation techniques right there. Indeed.

You cannot anyway lie to everybody forever. On the other hand, it's a good excuse to sleep through your workday. Oh, God. Right, that's probably it for today and for this year. So yeah, happy holidays and I'll speak to you in the new year. Have a good one. Thank you. Bye. Thank you, Gleb. Cheers.