C++ Weekly - Ep 323 - C++23's auto{} and auto()

[@not_ever]

That motivating example is a bug that will happen to me in a year's time or so and I won't remember wtf is happening

[@neilweidinger]

hate to be the rust shill, but this would be trivially caught at compile time by the rust compiler, meaning this bug would *never* even be possible

[@AxWarhawk]

Yep, seeing that usage of std::erase makes me think: this looks like a high caliber foot gun! Great job 🙄.

[@rauldragu9447]

But wouldn't it have been better if this was implemented in the standard library instead of the language itself? I mean we already have std::move(), std::ref(), std::cref() (and even std::as_const()). I feel like std::copy() or std::as_copy() would have fit in better and would be more readable and intuitive than adding an extra edge case to auto.

[@UpstreamNL]

Yeah. If I saw code with "auto{x}" in it, I would have no clue what it actually does. Some kind of weird cast or check? But seeing "std::copy(x)", it is immediately clear: it's making a copy of x

[@aDifferentJT]

Indeed, everything I’ve heard about the committee says that adding library features is much easier than language features so this strikes me as odd.

[@theRECONN]

@@aDifferentJT First of all, std::copy already exists. Secondly, this requires fetching a library. The committee wants this as a language feature to be able to reason about standardization easier. For example, defining concepts for Ranges previously required a function called "__decay_copy", but this required an exposition-only definition and wasn't really that intuitive as it looks. Having it as a language feature makes it part of the family and can be used to define stuff. It's not an algorithm that is likely to change internally.

[@keris3920]

I guess I don't see how. Consider the case of "my_type my_var{};". It's clear that this is just default initialized "my_type" named "my_var". But you can also do "my_type{}" to make an unnamed rvalue. I haven't looked it up yet to read some of the details, but it stands to reason that "auto my_var{other_var};" just deduces the type of "my_var" and calls the copy constructor. So it stands to reason that "auto{other_var};" does exactly the same thing, it is just creating an unnamed copy instead of a named copy.

[@UpstreamNL]

@@theRECONN there does not exist an overload of std::copy yet with one argument. Same with std::move which has overloads for one argument, but also a multi-argument version for iterators

[@jhbonarius]

In C++69 you'll just have to write one single "auto" and the compiler wil do everything else for you

[@rauldragu9447]

auto main(auto argc, auto argv) { auto result = int{ 0 }; return auto{ result }; }

[@rauldragu9447]

@@jhbonarius I mean that's actually C++23, we are already living in that reality. And unfortunately, if we keep up the 3 years between standards for that long, we will only reach C++68. But yeah, by that point the compiler will most likely employ AI to generate code auto-matically based on market trends, the programmer will only need to know the magical command line arguments to invoke it. And since we use a new build of the compiler to rebuild the compiler in a more optimized version, this means that it would take over development of itself, most likely leading to a skynet scenario.

[@jhbonarius]

@@rauldragu9447 C++69 will be the exception. Like C++42

[@rauldragu9447]

@@jhbonarius Yeah, if they delay a single release, a single year, then both would work

[@ShadowaOsu]

@@rauldragu9447 i have no information if there's been a change about it but if there isn't, that above code shouldn't work in C++23 because templating main function is not allowed. Using "auto" as parameter type will make the any function implicitly templated.

[@petermuller608]

The title made me fear a subtile difference between auto{} and auto() xD

[@lichray]

Same thing. Just a style choice.

[@fcolecumberri]

sooo... why it is auto{} and not std::copy() ? I mean, we have std::move() to move, why not std::copy() to copy?

[@emiliancioca]

that's a great question! Allow me to explain:

[@matthieud.1131]

Because std::copy already exists, with a different meaning, and even though the existing versions of std::copy take at least 3 parameters, having an overload for 1 parameter that does something entirely different would be confusing. That would be my guess.

[@friedkeenan]

Fun fact STL implementations usually have a "private" decay_copy function that does this. Personally I find the language feature more compelling though

[@treyquattro]

I did think it was an opportunity for a std::copy(). Also, why is move() in the standard library and not the language since it's intrinsically necessary post-C++11?

[@treyquattro]

@@matthieud.1131 then there should be a clone() as with C#

[@treyquattro]

I would not have expected that erase behavior! Work-around good to know ... sort-of.

[@qsvui]

what exactly was the issue with declaring an explicit variable to make a copy instead of trying to be clever and cramming everything into one line?

[@cppweekly]

They have two very different meanings if the function you are passing it to takes by forwarding reference or by value. If you make an explicit local variable then you are going to get an extra copy, unless you explicitly use `std::move` which means you are getting possibly an extra move. If you pass a temporary directly to the function call the compiler can do more things *and* you get the bonus of not having an extra named variable in scope and the question of "hey, why is this variable here again?"

[@BartTrojanowski]

quite the footgun we have there.

[@nmmm2000]

In the past, I saw special cast for it. syntax was very complex I do not remember it, but it allowed to bind values to functions like "void f(int &&)"

[@oschonrock]

ok. cool. and what is `auto()` ... is that the same thing? (non-narrowing doesn't / can't apply here?)

[@treyquattro]

probably a most vexing parse...

[@stephenhowe4107]

Unless I missed it, I saw auto{} covered. But what about auto()? Thanks

[@killerbee.13]

It's the same, basically. Normally the difference between () and {} is whether narrowing conversions are allowed, but this is a same-type cast which is obviously never narrowing. If there is any real difference, I hope never to run into it.

[@thevaf2825]

great coverage of a terrible situation...

[@someonespecial1329]

What IDE are you using?

[@cppweekly]

compiler-explorer.com

[@regbot4432]

Confusing but yet elegant

[@Cornyfisch]

I think these two concepts oppose.

[@regbot4432]

@@Cornyfisch ;)

[@siggimund]

@@regbot4432 I think we share the same sense of humor 😂

[@faraanhadi]

Why am I getting a notification today when this was uploaded 3 days ago team KZbin fix this

[@christophclear1438]

It's unlikely _remove_if_ will swap anything. It can just do moves instead.

[@fcolecumberri]

Jason!!!! Nvidia has just free their linux kernel driver, please make a video reviewing the code (I know it's C and not C++... but still).

[@organichand-pickedfree-ran1463]

Couldnt you fix this by just adding one line that makes a copy of the value? All this syntax in modern C++ is over the top. [&,=,&a](){} was also unlike anything before. Taking existing words and change their meaning.

[@bo-dg3bh]

Great video. At first I thought that was ur typing speed..

[@hanyanglee9018]

auto++

[@hiftu]

Yeah, reference semantics can bite you in the ... body.

[@technologicalwaste7612]

Overloads are a code smell.

[@victoreijkhout6146]

Neat!

[@djouze00]

I used to love C++ a lot, nowadays I'm more inclined towards C and Rust.... I mean, I feel like the language and the standard is constantly getting more and more bloated and confusing. I feel like I never know what's going behind the scenes anymore. There are so many hidden things and special rules. I like consistency, and I think we are at a moment that has so much stuff and all a lot of it just lacks consistency. PS: I feel like I shouldn't have to say that, but it's *MY* opinion. PS: No, I'm not a Rust fanatic, I'd rather write code in plain C to be honest.

[@patricktorgerson5810]

You should check out Zig. It's quickly becoming one of my favorite languages

[@djouze00]

@@patricktorgerson5810 Thank you for the tip! Though it might become a little bit like Rust for me, in the sense that I only use out of curiosity and etc, thankfully all my work is based on C. Either way! Do you have any content about it that you think is cool to share?

[@Evan490BC]

@@patricktorgerson5810 Zig is elegant, but it lacks two things that I find absolutely essential for my work: operator overloading and (some kind of) destructors.

[@free_mind]

I understand your opinion on C++. It definitely requires more time to be on top of the new features compared to other languages. I must disagree about using C instead of C++ however. Yes, C's rules are incredibly simple. That's why Linus Torvalds uses it for the Linux kernel, since just looking at it is enough to see the assembly that it would generate. However, by using C, you give up the plethora of GOOD additions that C++ added to C. In large codebases, C becomes a nightmare. In C, everything is in the global namespace, macros, magic C-style casts that are always allowed. No RAII makes code much more difficult to reason about, no generic programming, limited compile-time programming, small standard library, etc. You don't need to know everything. Just understand how the core of the language works, such as move-semantics, rule of 5/rule of zero class design, and the more complicated stuff will be much easier to understand. Once I took my time to learn modern C++, I really understood the motivation behind more things and it just all sort of fell into place. Yes I give you the language is very complex and has a bloated feature set, because many people with different design philosophies contributed to it since the C++98 standard. I claim that all languages with a legacy as long as C++ will eventually run into the same problems as C++. Rust is the true competitor to C++, not C, since Rust attempts to fit in the same niche of application/systems level programming that C++ is used for. I wish it well, and I gave it go. But the problems in C++ that Rust tries to solve never really occurred in my company's codebase, where we write modern C++

[@djouze00]

@@free_mind I totally understand you too! I do like C exactly for the reasons you cited! And *yes* I'm annoyed by some of the stuff that we don't have in the language, namespaces are a big thing for me, and in C it's horrible to have everything in the global namespace.

[@Carutsu]

as usual add more crap because the crap we added is completely unintuitive and broken. I think I'm quitting c++

[@leonmunster8972]

I know that feeling. But I don't know were to switch to so I'm staying for now.

[@proloycodes]

try Rust, it does not even let you compile the example that the video gave (translated to Rust of course)

[@anon_y_mousse]

@@leonmunster8972 Try plain C. Learn the 89 and 99 standards and stick with it for a while. Maybe read newer standards after that, maybe craft your own language.

[@leonmunster8972]

@@anon_y_mousse I guess my main problem is that I like having quite a few of c++ features, it's just all the weird edge cases that i have a problem with. What I write is mostly c with some c++ (like templates and overloading when helpful), but I don't think that I ever tried just plain c.