Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Move in C++ without a std:move

andreasfertig.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Move in C++ without a std:move

#61

Post by ahartmetz »

account42 wrote: post #56
locknitpicker wrote: post #50

Earlier quoted context omitted.

> Template resolution solved that in the past, but C++ today allows auto in so many places that I'm uncertain that it can be done without some flow based support (if constexpr comes to mind). This concern is unfounded. The auto keyword in C++ acts as mere syntactic sugar. It works only when the compiler is able to tell exactly what's the type by evaluating the expression. The auto keyword is also considered a code sm…

> The auto keyword is also considered a code smell for the same reason: just because the compiler can tell exactly what the type is expected to be, that does not mean the developer can. Therefore it makes the code harder to reason about. This really depends though. In many cases even the programmer can tell the type of auto because its on the very same line and not using auto would mean needlessly repeating it. In ot…

GP was possibly arguing against Herb Sutter's "almost always auto". C++ wasn't designed for auto and it shows. You can't rely on it always doing the right thing or at least a safe thing in C++, unlike in Rust - I've seen bugs due to auto. It is also often helpful to spell out the concrete type in important places such as (most/many) variable definitions.

I'm also fine with auto if it just repeats information, especially so if the concrete type takes half of your line length budget (yes it's an iterator over that container containing...).

Re: Move in C++ without a std:move

#62

Post by ericpiker »

Implicit move from a variable of type Apple&& is gross, because that reference could refer to something that is not expected to be moved-from.

Granted you'd have to be pretty stupid to end up in that situation deliberately. You could accidentally do it and have a bug when you set your computer to C++23.

Re: Move in C++ without a std:move

#63

Post by reactordev »

dkenyser wrote: post #22
tom_ wrote: post #4

If the author is reading: both complicated examples are the same.

I swear I was staring at these two examples for longer than I care to admit wondering if I was just blind or dumb or both.

It's modern C++ so, a little of both I think. 20 years of it and I still have people saying "I should work on my fundamentals" so it's totally fine to be a bit of both.

Re: Move in C++ without a std:move

#64

Post by bluGill »

locknitpicker wrote: post #49
fluoridation wrote: post #5

Unfortunately, I don't think there's getting away from just understanding value semantics to get the correct and/or performant behavior.

> Unfortunately, I don't think there's getting away from just understanding value semantics to get the correct and/or performant behavior. This is not specific to C++ though. It just so happens that C++ developers who feel this topic is important are those invested in performance optimization. For them, C++ offers them these types of tools. Meanwhile, those who don't have a pressing need to go through great extents t…

> pay the performance tax of doing deep copies by default.

For most code that performance tax is not worth worrying about. There are almost high performance priorities. It is almost always the case that your code runs "fast enough" long before you start worrying about the few nanoseconds a deep copy of a few bytes costs.

Re: Move in C++ without a std:move

#65

Post by bluGill »

ahartmetz wrote: post #61
account42 wrote: post #56

Earlier quoted context omitted.

> The auto keyword is also considered a code smell for the same reason: just because the compiler can tell exactly what the type is expected to be, that does not mean the developer can. Therefore it makes the code harder to reason about. This really depends though. In many cases even the programmer can tell the type of auto because its on the very same line and not using auto would mean needlessly repeating it. In ot…

GP was possibly arguing against Herb Sutter's "almost always auto". C++ wasn't designed for auto and it shows. You can't rely on it always doing the right thing or at least a safe thing in C++, unlike in Rust - I've seen bugs due to auto. It is also often helpful to spell out the concrete type in important places such as (most/many) variable definitions. I'm also fine with auto if it just repeats information, especia…

Yeah, when auto first came out a few people started abusing it everywhere making for unreadable code. Most developers settled quickly on much better rules for using auto that do not destroy readability, and never abused it in the first place. Auto is intended for and works very well to avoid typing very long types where you often never care.

Iterators is the common example: the type name is always long, and nearly always used in a context where it is obvious. Even if you do care about the type, looking up the iterator is wrong - you always first look up the base type (ie std:vector) first to understand the iterator, only rarely do you need to dig into the iterator once you understand the base type.

Generic code (template and non-template) are the other - they type could be anything, so trying to specify more detail isn't going to gain you anything.

Re: Move in C++ without a std:move

#66

Post by bogwog »

vivzkestrel wrote: post #35

- stupid question, since we are on the topic of c++, i finished reading through learncpp.com - how do I take this from 0 to the guy that builds a play station 3 emulator? - like seriously what kind of step by step projects or learning experiences in increasing order of difficulty do you recommend to get really really good at c++

There's no simple universal roadmap for becoming competent. You just need to grind out whatever skill you're trying to master as much as possible. 10000 hours is the common number thrown around, but plenty of programmers have been doing it for more than that and can't even tell you how an emulator is supposed to work.

So to answer your question: work longer and harder than the people who don't know how to write a PS3 emulator (especially those who think they can take a shortcut with AI)

Re: Move in C++ without a std:move

#67

Post by bogwog »

nayuki wrote: post #39

Kudos to the author for explaining these concepts, but I personally find this to be a poor use of my time and mental capacity. I dabbled in C++ programming before Rust 1.0 was released (year 2015). I have spent some time understanding things like RVO, std::move(), rvalue references, T&&, move constructors, and so on. This was the main tutorial that I read a decade ago: https://web.archive.org/web/20240108142848/http:…

> I failed to understand something, but it's everyone else's fault

Re: Move in C++ without a std:move

#69

Post by locknitpicker »

bluGill wrote: post #64
locknitpicker wrote: post #49

Earlier quoted context omitted.

> Unfortunately, I don't think there's getting away from just understanding value semantics to get the correct and/or performant behavior. This is not specific to C++ though. It just so happens that C++ developers who feel this topic is important are those invested in performance optimization. For them, C++ offers them these types of tools. Meanwhile, those who don't have a pressing need to go through great extents t…

> pay the performance tax of doing deep copies by default. For most code that performance tax is not worth worrying about. There are almost high performance priorities. It is almost always the case that your code runs "fast enough" long before you start worrying about the few nanoseconds a deep copy of a few bytes costs.

> For most code that performance tax is not worth worrying about.

Indeed, I agree. It's possible to go a long way in terms of performance with a basic understanding of passing by reference, without even having ro bother with move semantics. So these topics end up being dominated by language lawyers and the types that enjoy debating "aktualy" topics, who also contribute to making things sound far harder than what they actually are by pretending that this sort of trivia is very important stuff.

Re: Move in C++ without a std:move

#70

Post by bluGill »

locknitpicker wrote: post #69
bluGill wrote: post #64

Earlier quoted context omitted.

> pay the performance tax of doing deep copies by default. For most code that performance tax is not worth worrying about. There are almost high performance priorities. It is almost always the case that your code runs "fast enough" long before you start worrying about the few nanoseconds a deep copy of a few bytes costs.

> For most code that performance tax is not worth worrying about. Indeed, I agree. It's possible to go a long way in terms of performance with a basic understanding of passing by reference, without even having ro bother with move semantics. So these topics end up being dominated by language lawyers and the types that enjoy debating "aktualy" topics, who also contribute to making things sound far harder than what they…

> So these topics end up being dominated by language lawyers and the types that enjoy debating "aktualy" topics,

I'm not sure about that.

Even though most people never need it, a small minority really do, and those types have to become expert in those weird details. Well you pretty much have to be a language lawyer to get these optimizations right, but the goal really is the ultimate performance in some place where it really matters.

Post reply on HN