Should I pass by const reference or by value?
HTML-код
- Опубликовано: 7 мар 2023
- Support ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
Code ► github.com/MariuszDot/Game_Fl...
Related C++ videos
lvalues and rvalues in C++ ► • lvalues and rvalues in...
Move Semantics in C++ ► • Move Semantics in C++
Links to stuff I use (helps support the channel):
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK
Absolutely good idea. Divide the videos into multiple topics 🙏
+1
+1
+1
Yup. This is the first code review video I've watched, so it definitely works 😃.
+1
As a newbie programmer in C/C++, I use const references all the time, but I never truly understand when or why I should pass by const reference or by value. I learned a lot from today's video and am looking forward to seeing short films that focus on specific topics. Huge thanks!
personally, i like to assume a default for how i use language features, and then get more specific (e.g., using "const", references, pointers, typename vs classname, etc..) when that clarity becomes important.
assume the default "int foo(int x)", and then attach all the modifiers that declare more specificity of your function.
ex:
float sin(float th) -> float sin(const float th) -> constexpr float sin(const float th)
The main takeaway is, if it fits in a register then the compiler can keep the VALUE in the register (and optimisation to avoid stack read writes.) No memory bus access required.
A reference *is* a pointer in hardware terms, which always requires memory access because it's hard to optimise, which is comparatively slow.
Source: I'm a bare metal C++ firmware engineer and this stuff makes a huge difference in my 32 bit world!
I am trying to pass by value whenever it's possible to avoid extra copies. Because, you know, move exists. And it is more efficient to pass std::vector by value (also don't have problems with aliasing if you pass TWO vectors). And almost every other 'expensive copy' as well.
@mapron1
"I am trying to pass by value whenever it's possible to avoid extra copies."
That sounds quite contradictory, don't you think? Passing by value means copy construction which logically implies that a copy is to be created.
"Because, you know, move exists."
I don't think move semantics should be involved as it serves a different purpose. Moving logically implies transferring of content and resources, which is different from just trying to read data.
`std::vector` becomes more and more expensive to copy the more elements it has.
In most cases, the point of accessing the value through a const reference is to avoid unnecessary copying of read-only data. For trivial types that can fit in a CPU register, sure, a copy is fine. But for types like `std::vector`, you might want to use references instead.
@@ajtan2607 Passing by value means copy construction which logically implies that a copy is to be created.
That just not true. modern C++ is all about value semantics.
> But for types like `std::vector`, you might want to use references instead.
No you don't. Just get used to move everywhere.
if you don't need vector data, only like, well, reference - don't pass a vector, pass std::span argument. otherwisse 99% you need pass by value.
sigh... Understandable, beating 30 years of habits is hard.
Also you need to be consistent - taking my advice in legacy codebase when only file follows new rules is just a harm.
A completely agree with you that passing primitive data types by reference is not a great idea. It will most likely prevent compiler optimizations. However, I think its probably a good idea to pass custom types by reference, even if they are small. The reason being that their size (and internal behavior) can easily change in the future, without the programmer later realizing that these function parameters all need updated to reference types. After 20 years of programming, one thing I've learned is to treat everything I've touched as unstable and dynamic.
damn
I heartily approve of doing the code reviews by topic. If it tells you anything, this is the very first one of your code reviews I've ever watched--specifically because it wasn't ridiculously long, and I could see in the title that it was about something I might find useful.
You might get fewer views per individual video this way, but I have a feeling you'll get *way* more total views overall.
I don't agree, I think he'll get even more views per video because they'll be short and more focused.
Same here. I once started like a 1h video of code review, but quickly I got lost and never finished.
Instead, for this quick video I already entered knowing what was the topic, was direct to the point, easier to understand and, well, I saw to the end.
I like the idea of splitting the code review video by topic! It taught me a lot. Hope to see you sharing more videos like this in the future.
This was definitely more easily digestible and focussed than 40 minutes of code review that goes in five different directions. I smashed like so hard on this that I almost dropped my phone.
Great Idea go for it. That is the exact reason why I watch long code review videos.
At any random time in a video, you give a specific knowledge for a specific situation that normal learning seriea doesn't even think about to teach us.
For example this video enlighten me about r and l-values. Thank you for that. Learned C++ with your C++ series years ago and now I can develop custom tools for the games I make with Unreal Engine.
This format is a good idea, and you could also add this video to the C++ series as it covers a pretty interesting topic that fits into it ! Cheers
Heheheh... i know fools who const reference everything even boolean types and I'm like... 🤦♂🤦♂🤦♂
100% love the shorter videos. Recently I haven't been able to find the time watch longer code review videos, so breaking them down makes it much easier
As you said, a big video on this would be really cool. Thanks for all your work :)
Making small videos for certain topics is very good idea. Never watch your code review videos before, but watched this video because of intresting topic. Often was asking myself the same question, and now I have an answer. Thanks a lot!
I really like the short, by topic code review!
I look forward to your bigger video on this :) I also enjoy this style of code review more, it's more descriptive to what the video goes over
Yes!!! Please do that! Splitting it into parts and explaining different topic on each video would be so much helpful!
making short code review responses that address very specific topics would be perfect for...well, shorts!
I've seen a couple channels try out short "tips & tricks" videos around code and they've been very useful!!
Very insightful as always Cherno thanks!
Such a good idea!
Please, more of these short videos!
Really valid topic! Varies in a lot of things - threads and coroutines make things slightly trickier, but nice video
9:43 yes! this is a fantastic idea. I only clicked on this because the title was interesting. I never click on code review videos
love seeing this short and sweet!!
this is absolutely a better format, not only because my attention span is garbage
but also it really helps to build a library of "advice" video that's easily searchable even without the context of the code review
this kind of advice is quite rare in a normal beginner tutorial and StackOverflow can be quite asinine about it
this way your video can reach a broader audience who just need specific advice
Fantastic topic, helps a lot about programming futures. Nice video
Divide by multiple topics, that will help your channel on the long term as more videos will popup on RUclips search. And that will help less skilled programmers(like me) to learn specific topics.
I just want to join all those that have said that it is an excellent idea to divide the code reviews into smaller videos focusing on one concept. It is super useful!!! Also, you get the opportunity to explain the same concept in multiple and different code sets which will greatly help understand better the concept, you know, by looking at it from different angles and use cases.
Very good idea - the fact to show more shorted (but specific) videos is (imho) more interesting and more appealing than big review videos.
@thecherno3 OMG thank you! What did I won?! I can’t believe it! It is amaaaaaaaaazing! I hope you’re not a fake OMG! I hope it is a house! Is it a house? Or a 35 levels building in the middle of Central Park?! Or, more amazing, 15kg of twinkies!!!! I hope this is not fake OMG! WHAT IS A DM? HOW TO DM? WHAT IS THE PURPOSE OF LIFE?! WILL « TRON 3 » BE A GOOD TRON SEQUEL? SO MUCH QUESTIONS!!!!!!!
I love this video format!
That "it gots darker here" got me 😂
Splitting a long code review into more specific and shorter videos is a fantastic idea. As you said anyone could focus on particular topics that may be intersted in and understand a topic better without being overwhelmed
Great video as always!
The short form videos I think are a lot better because, as you said, the video is more on-topic but not all over the place.
However, I think for every code review you should first make a video to overview the project and show the improvements that you would do, maybe explaining briefly (not focus on just one improvement, like the flying dog game video) and then make separate videos on every important topic, explaining it in detail (just like you did in this video).
Good idea. Shorter videos but more specific targeting a given concept or issue. It 's gonna be more interesting.
Love these series!
Definitely prefer this format more than a longer video as it is easily digestible. It could also be more useful for people who just need information on a specific topic
I think, at least for me, it'll be easier to learn and digest your videos in a smaller chunks format like how you use to do C++ tutorial. It'll also be easier to see what specific topic you're covering specifically and if later I need to come back to it, it'll be easier to search as well. Just my thought though. You're still one of my best mentor for programming :)
By topic sounds (and works in this instance) great!
Holy shit I searching for something like this just a day or two ago. Chreno-sama smiles upon me 🙏
Splitting it up into smaller more specific videos does seem like a good idea. Really liked this one and got a pretty in depth explanation. Unlike general code review videos where you probably wouldve just said a few things and then kept going.
This video is good advice, it's basically F.16 in the cpp core guidelines: For “in” parameters, pass cheaply-copied types by value and others by reference to const. F.15 has a really good diagram that illustrates all the choices.
IMO it's a good idea to keep your argument definitions 'const', even when receiving value types. Especially in larger methods it's useful to know for certain that a given argument hasn't changed.
Also, don't use 'new', 'array'/'vector' would trivially give you the all-important move constructor for that buffer.
thank you for clearing this confusion on my part!!
The part of the video where you said you should probably make an entire video about, I think it was around 2:15, that would be very helpful. The CPU is still very much unknown to me. And individual videos would be great especially as a playlist too.
Just look at the assembly code my friend, I bet you will get a couple of surprises, particularly with private methods. Hint: the compiler does not always honour the argument passing convention you specified
can you go into a bit more detail? what exactly are you referring to
@@andyyy1094 I mean that you can write code meant to pass or return parameters by value, particularly long structs, but the compiler may decide to pass them by constant reference if such parameters are not modified inside the function and the function is contained in the same translation unit (C static function, or C++ private method). Furthermore, even if the function is not private, some compilers can go a step further and create two versions of the same function, one to be called (often inlined) using references when invoked from the same translation unit (regardless of what passing convention you specified), and another one ready for external calls. However, what is said in the video is correct and programmers should keep with good practices and never assume that the compiler will optimise everything
Dont trust the compiler on everything, especially if you want to run things in debug mode.
@@urisinger3412 What you mean by don't trust the compiler? Compilers are by far the most trustable pieces of software in existence. Can't imagine the mess if it wasn't like that
@@RelayComputer dont trust the compiler to optimize every stupid thing you do, they dont catch everything and those little things can add up
Explaining the "why" of anything is extremely valuable, at least imho. throughout all of your content that I have watched, the most enjoyable is when you explain quite trivial things but explain the reasoning at a really low level.
This format would indeed be better than the massive code reviews, i skip those but this had a title that described what was being talked about and interested me and turned out to be useful.
i really liked this one. It's short and it's about one specific topic.
I found it useful, and I am more willing to watch a short video about a specific problem/thing in the code.
I agree that dividing the videos will make them more "digestable" but your content is so good that I wouldn't mind to watch hours of video... I work with C++ nowadays and there some videos that I have watched several times... Thanks for the sharing your amazing knowledge.
Hi Cherno. Love your work! Could you please do a c++ video on implementing a finite state machine?
I also like the idea of splitting the code review into shorter videos. This let‘s one pick the topics of interest quickly and it‘s also easier to „digest“ ;-).
Go for it man!
Never thought of this whenever using passing by const reference. Cherno sir 👌
Multiple topic videos per review would be great!
Good idea to split the review up👍
Very real and useful advice going on here
So happy I'm not coding in C++ anymore. I use Nim and it checks the size of what you pass and chooses by reference or value at compile time. So if you pass an object, it gets sent as reference if it's above a certain threshold. Ints gets passed by value unless you use "var" (mutable reference).
As someone who was actually wondering about this thing in particular I very much aprove the idea of making code reviews as by topic rather than long format they used to be.
new idea is great!
Hi, can you please make a detailed video of how virtual table works in the context of virtual functions?
very deep video about basics , thx
static_assert(std::is_trivially_copyable_t); Type trait can be used to test if your type is trivially copyable.
I agree. Good idea.
I liked this format, short videos are better to be referred later too
Good idea Cherno! Clicked on this vid because it was not 01h and 40min long for example =)
Yeah, that sounds like a good idea ^^
I think dividing code review based on topics would be great!
It's also nice to understand the difference between passing by value as 'const uint32_t' or 'uint32_t'. Assuming the argument is in a register, for 'const uint32_t' compiler is safe not to create a copy, while for 'uint32_t' it might allocate another register as this argument might be changed inside a function.
For example:
uint32_t sum(uint32_t n) { uint32_t sum = 0; while (n > 0) sum += n--; return sum; }
finally a c++ video :)
❤❤❤
I like the idea of splitting up the code review my topic.
yep split the reviews up!
Yes, please. Short videos on a specific topics
I like your idea to divide videos
Another thing to consider is that unnecessary passing by pointer/reference can also prevent the compiler from making certain microoptimizations
Oh shit I thought Const ref would help as opposed to impede that
@@DaddyFrosty It is exactly like that. Using const ref gives the compiler perfect information, it can choose to copy or not the uint. People who don't understand this and just spit out the "pass small types by value" ideology from 30 years ago, are frankly clueless. Const reference isn't some promise to use a pointer, it represents the abstraction of a read only object that already exists somewhere.
@@teranyan C++ Core Guidelines F.16: For “in” parameters, pass cheaply-copied types by value and others by reference to const
@@teranyan It depends on the function.
Say something like "void multiplyVectorByValue( std::vector& vec, const& val)" - iterating over the vector and multiplying every member by val. here passing by reference can be a serious detriment if the compiler can not proof that "val" is not part of "vec" - cause then it has to re-load val on every iteration, preventing any loop-hoisting or vectorisation.
nice video. Anyway I watched a lot of your videos and one think that i will remember for sure is "kind of", "kind of", "kind of"
Also shallow copy have very interesting thing to do with.
На современных процессорах объекты размером до 8 указателей (32/64 байта) можно смело передавать по значению. Без глубокого копирования указателей на кучу, естественно.
fwiw, the "built-in C++ type" is std::uint32_t. uint32_t is a C alias that most (all major) C++ std library implementations happen to provide, but isn't part of the std
Man you are God to me!
I prefer to watch the code review split into smaller topics. Makes it easier to process and I search it, should I ever want to rewatch it.
Yes good idea to split!!
Wow! Finally my decade long question has been answered :-)
yeah shorter more focused videos sounds like a good idea, but i gotta say i really do like this format i end up learning alot regardless
and theres room for jokes and other tidbits which honestly makes me wanna watch your videos more, cuz i mean think abuot it there are plenty of c++ videos on youtube, people watch yours because of your personality, and that doesnt just include the way you teach but also the videos are just entertaining too
As pointers of course! ;o) 😄
I like the Qt style: pass c++ (std)types by value, Qt objects by reference, and Qt objects where you transfer ownership by ptr
Regarding monolithic code reviews vs snippets about specific coding issues, I vote for the latter. Bits of info about specific topics seems better (IMHO).
Yes, it's a good idea to split the video into topics.
Thanks, yes better format.
Well, you only need to use a const if that reference or data type is needed else ware in the code file. If not then go the value type route if it is not used anywhere else but once to declare a value.
Dynamic vs static values used once or more. Depends..
This is one of the few times when I actually agree with the design of C++. Since references are mostly transparent you can start with just passing by value and should you change to a more complex object in the future merely change the signature to include a const reference and have little trouble. Some languages make the boneheaded decision of either removing pointers and explicit reference documentation and everything is a reference. Some make the equally boneheaded decision of making references explicit all around which basically means they're just pointers. C++ actually did it right here.
references are just non-nullable pointers with a '.' accessor instead of '->'. who knows why k&r chose '->' instead of '.', but hey now we're stuck with it.
@@Spongmanbecause it’s already used for normal objects. You can also use it with pointers but you gotta dereference them first, leaving you this
(*obj).member
And it becomes hard to handle when you deal with nested pointers like this:
(*(*(*obj).member).attr).val
So they invented -> to avoid typing the above
obj->member->attr->val
@@Ich_liebe_brezeln you missed my point. I’m saying that k&r could have just used ‘.’ for pointer indirect without ambiguity, since pointers themselves don’t have members.
Your last expression could easily have been ‘obj.member.attr.val’.
@@Spongman Oh well, now I get your point and I guess is not a bad idea. Maybe they wanted you to remember that you were dealing with pointers at all times… or didn’t really think that much about that.
9:42 that's a good idea everyone will be able to watch those small videos and learn something new, like i did in this video ;)
Love this style of broken-up code review, but it would be nice if there was some indication that this is actually a code review, like maybe on the thumbnail
9:45 like the new idea :)
Have you ever seen a case where passing by reference was better due to the reduced set of memory pages being used? I could imagine a case where it would help with TLB hits in the CPU?
Honestly surprised this isn't handled by the compiler.
Personally, both formats (longer video with timestamps) as well as short formats that are just focused on one part are fine. I'd say make the choice based on what gets more views (without having to resort to click-baity titles / screencaps with those "shocked face" looks).
Please do the small talks about this topics 🥺🙏
Agree with others, I think the length and content of this video is much more preferable to your longer videos. Easier to digest etc.
I like that idea
Oh no, watching The Cherno's videos gets me excited about copying memory and pointers and whatnot in C++, I don't want to dive into this rabbit hole again *starts editing makefile* oooooooh nooooooooooo what have you dooooooooooone Chernoooooooooooo
multiples short videos rocks!!!!!!!
Making more little videos is a great idea !
Would love if you did that
I think the problem is that the ide, highlights it if you dont use a const reference, i just noticed it as i was working on my project