I thought another reason for having a single return point was to make sure the compiler performs RVO? I'd heard(can't recall where though) that if you returned different variables throughout your function that the compiler can't correctly perform RVO, but if you have a single return RVO is much more likely(and guaranteed since c++17). Was I misinformed on this, or has something changed?
A single return _may_ enable RVO - but is that an argument to use single return by default everywhere? I'd say no. Forcing yourself to a single return just to get a performance benefit that in most cases is hardly measurable and in almost all cases does not happen in performance critical paths of your software is definitely premature optimization. If you happen to find a function that is in your inner loop and that does benefit from RVO when you switch to a single return, then go ahead (after measuring, of course). But then also consider using out-references and overwriting existing objects instead of creating new ones that your function returns.
If you have potentially multiple objects being returned (think 2 objects, than some sort of branch and returning one of the two objects) RVO sometimes isn't performed. If the objects are constructed in their respective branches instead of a common area you'll get RVO. Should answer well enough.
33:56 but why would you design for non-copyabilitywhen changing the reference to a pointer is easy. If it _works_ when its copied, if its not a _mistake_ to copy it, then there's no reason to maim the design. If OTOH it _is_ a mistake to your quote randomizer service, then you should be deleting the copy constructor.
The class contains a rng generator and also usedQuotes which is something like a history. Now if you copy it it will generate the same output multiple times. That's not good, especially by accident when passing it to another function. So I think it is best to make non copyable.
some things are by nature not copyable, more over, some classes should behave like references (specifically, non-values). By containing a reference, you make these kind of classes non-copyable by default (you don't even need to delete the copy constructor). If you instead use a pointer as member in this kind of "reference" classes, you need to make sure that you delete the copy constructor, and you have to make sure that the pointer is not set to null or reseated accidentally (use of non_null is horrible, and doesn't solve the problem of reseating a pointer). Of course if you want to make your class copyable, this is because it is not a true reference class, so these above do not apply.
I don't exactly get what you mean just from hearing from your timestamp to 35:27, so I'll have to guess your intention. You (usually) don't copy in-memory repositories because they usually contain way too much data to be just copied and then discarded. "Real" repositories like a db-connection cannot really be copied because that is (usually) a shared resource and could lead to issues down the road when being shared without maintaining the state between each copy. So it's simpler to prevent any form of copying to prevent footguns for other devs or myself in six months.
Pointers and references have different semantics, they shouldn't be interchangeable (unless you like C that much). However, I agree with your comment on deleting the copy constructor for expressing non copyable types.
Excellent common sense presentation
I thought another reason for having a single return point was to make sure the compiler performs RVO? I'd heard(can't recall where though) that if you returned different variables throughout your function that the compiler can't correctly perform RVO, but if you have a single return RVO is much more likely(and guaranteed since c++17). Was I misinformed on this, or has something changed?
A single return _may_ enable RVO - but is that an argument to use single return by default everywhere? I'd say no. Forcing yourself to a single return just to get a performance benefit that in most cases is hardly measurable and in almost all cases does not happen in performance critical paths of your software is definitely premature optimization.
If you happen to find a function that is in your inner loop and that does benefit from RVO when you switch to a single return, then go ahead (after measuring, of course). But then also consider using out-references and overwriting existing objects instead of creating new ones that your function returns.
If you have potentially multiple objects being returned (think 2 objects, than some sort of branch and returning one of the two objects) RVO sometimes isn't performed. If the objects are constructed in their respective branches instead of a common area you'll get RVO. Should answer well enough.
this was brought up in the talk
Good talk bro
33:56 but why would you design for non-copyabilitywhen changing the reference to a pointer is easy. If it _works_ when its copied, if its not a _mistake_ to copy it, then there's no reason to maim the design. If OTOH it _is_ a mistake to your quote randomizer service, then you should be deleting the copy constructor.
The class contains a rng generator and also usedQuotes which is something like a history. Now if you copy it it will generate the same output multiple times. That's not good, especially by accident when passing it to another function. So I think it is best to make non copyable.
some things are by nature not copyable, more over, some classes should behave like references (specifically, non-values). By containing a reference, you make these kind of classes non-copyable by default (you don't even need to delete the copy constructor). If you instead use a pointer as member in this kind of "reference" classes, you need to make sure that you delete the copy constructor, and you have to make sure that the pointer is not set to null or reseated accidentally (use of non_null is horrible, and doesn't solve the problem of reseating a pointer). Of course if you want to make your class copyable, this is because it is not a true reference class, so these above do not apply.
I don't exactly get what you mean just from hearing from your timestamp to 35:27, so I'll have to guess your intention.
You (usually) don't copy in-memory repositories because they usually contain way too much data to be just copied and then discarded.
"Real" repositories like a db-connection cannot really be copied because that is (usually) a shared resource and could lead to issues down the road when being shared without maintaining the state between each copy.
So it's simpler to prevent any form of copying to prevent footguns for other devs or myself in six months.
Pointers and references have different semantics, they shouldn't be interchangeable (unless you like C that much). However, I agree with your comment on deleting the copy constructor for expressing non copyable types.