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
@neilweidinger2 жыл бұрын
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
@AxWarhawk2 жыл бұрын
Yep, seeing that usage of std::erase makes me think: this looks like a high caliber foot gun! Great job 🙄.
@rauldragu94472 жыл бұрын
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.
@UpstreamNL2 жыл бұрын
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
@aDifferentJT2 жыл бұрын
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.
@theRECONN2 жыл бұрын
@@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.
@keris39202 жыл бұрын
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.
@UpstreamNL2 жыл бұрын
@@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
@jhbonarius2 жыл бұрын
In C++69 you'll just have to write one single "auto" and the compiler wil do everything else for you
@rauldragu94472 жыл бұрын
auto main(auto argc, auto argv) { auto result = int{ 0 }; return auto{ result }; }
@rauldragu94472 жыл бұрын
@@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.
@jhbonarius2 жыл бұрын
@@rauldragu9447 C++69 will be the exception. Like C++42
@rauldragu94472 жыл бұрын
@@jhbonarius Yeah, if they delay a single release, a single year, then both would work
@ShadowaOsu2 жыл бұрын
@@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.
@petermuller6082 жыл бұрын
The title made me fear a subtile difference between auto{} and auto() xD
@lichray2 жыл бұрын
Same thing. Just a style choice.
@fcolecumberri2 жыл бұрын
sooo... why it is auto{} and not std::copy() ? I mean, we have std::move() to move, why not std::copy() to copy?
@emiliancioca2 жыл бұрын
that's a great question! Allow me to explain:
@matthieud.11312 жыл бұрын
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.
@friedkeenan2 жыл бұрын
Fun fact STL implementations usually have a "private" decay_copy function that does this. Personally I find the language feature more compelling though
@treyquattro2 жыл бұрын
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?
@treyquattro2 жыл бұрын
@@matthieud.1131 then there should be a clone() as with C#
@treyquattro2 жыл бұрын
I would not have expected that erase behavior! Work-around good to know ... sort-of.
@qsvui2 жыл бұрын
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?
@cppweekly2 жыл бұрын
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?"
@BartTrojanowski4 ай бұрын
quite the footgun we have there.
@nmmm20002 жыл бұрын
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 &&)"
@oschonrock2 жыл бұрын
ok. cool. and what is `auto()` ... is that the same thing? (non-narrowing doesn't / can't apply here?)
@treyquattro2 жыл бұрын
probably a most vexing parse...
@stephenhowe41072 жыл бұрын
Unless I missed it, I saw auto{} covered. But what about auto()? Thanks
@killerbee.132 жыл бұрын
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.
@thevaf28252 жыл бұрын
great coverage of a terrible situation...
@someonespecial13293 ай бұрын
What IDE are you using?
@cppweekly3 ай бұрын
compiler-explorer.com
@regbot44322 жыл бұрын
Confusing but yet elegant
@Cornyfisch2 жыл бұрын
I think these two concepts oppose.
@regbot44322 жыл бұрын
@@Cornyfisch ;)
@siggimund2 жыл бұрын
@@regbot4432 I think we share the same sense of humor 😂
@faraanhadi2 жыл бұрын
Why am I getting a notification today when this was uploaded 3 days ago team KZbin fix this
@christophclear14382 жыл бұрын
It's unlikely _remove_if_ will swap anything. It can just do moves instead.
@fcolecumberri2 жыл бұрын
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-ran14632 жыл бұрын
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-dg3bh2 жыл бұрын
Great video. At first I thought that was ur typing speed..
@hanyanglee90182 жыл бұрын
auto++
@hiftu6 ай бұрын
Yeah, reference semantics can bite you in the ... body.
@technologicalwaste76122 жыл бұрын
Overloads are a code smell.
@victoreijkhout61462 жыл бұрын
Neat!
@djouze002 жыл бұрын
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.
@patricktorgerson58102 жыл бұрын
You should check out Zig. It's quickly becoming one of my favorite languages
@djouze002 жыл бұрын
@@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?
@Evan490BC2 жыл бұрын
@@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_mind2 жыл бұрын
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++
@djouze002 жыл бұрын
@@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.
@Carutsu2 жыл бұрын
as usual add more crap because the crap we added is completely unintuitive and broken. I think I'm quitting c++
@leonmunster89722 жыл бұрын
I know that feeling. But I don't know were to switch to so I'm staying for now.
@proloycodes2 жыл бұрын
try Rust, it does not even let you compile the example that the video gave (translated to Rust of course)
@anon_y_mousse2 жыл бұрын
@@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.
@leonmunster89722 жыл бұрын
@@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.