On 24/03/2017 12:42, Bo Persson wrote:
On 2017-03-23 22:46, Gavin Lambert wrote:
On 23/03/2017 20:57, Olaf van der Spek wrote:
AFAIK string_ref should be passed by value, not by const&.
It's larger than a pointer. Ergo, pass by reference.
Granted it doesn't make a lot of difference as it's trivial to copy so that performance isn't much of an issue, but why waste stack/register space unnecessarily?
How about when *using* the parameter. Effectively passing a reference to a pointer may not be the best way to get high performance.
It makes no real difference. Any interaction with string_ref will be by calling member methods, which in turn require passing a pointer to the "this" instance (either on the stack or in register, depending on calling convention). Either way, it's the same thing -- it either passes the reference it already has as a pointer or it passes the address of the local copy. (Or more likely they'll be inlined.) It might possibly inject one extra stack indirection if the reference is still in the stack rather than in a register, but that'll be in L1 cache (at least near function entry) and be pretty darn fast anyway. If in doubt, profile it later. Performance is a tricksy beast, especially once you go multi-core. It's not that big a deal, though, in this case. But const& is still the safest default parameter style, until you can prove that copies are cheaper than a stack indirection (or that moves are, and you can always move). Don't even get me started on the people who think nothing of passing shared_ptrs around by value.