Let Go, Standard Library From Community

[Daniel Keep]

David B. Held wrote:
> Stephen Waits wrote:
>> [...]
>> I agree with you.. portability is preferred here, considering the
>> non-existent performance difference.
>>
>> I'd even go as far as saying that using bit twiddling in this specific
>> case is the "junior mistake".
>>
>> Why?  Because it assumes that the compiler isn't already taking care
>> of this for you.
>> [...]
> 
> To highlight this point, I interviewed a candidate the other day that
> agonized over the best way to return a vector from a C++ function in an
> efficient manner.  He considered heap-allocating it and returning a
> pointer (apparently, he thinks 'new' is fast), passing an out reference,
> and a few other things.  And yet, he didn't once mention the fact that
> he was passing *in* two vectors *by value*.  When I asked him the most
> efficient way to pass in the input vectors, I asked if he should do it
> by value, by reference, or by pointer.  He said: "By pointer".  Oy vai!
>  Apparently, he wasn't familiar with [N]RVO, and was optimizing the
> wrong thing.  90% of any given program contributes only 10% to its
> overall performance, typically.  That's why C.A.R. Hoare warned against
> the dangers of premature optimization (and making sure you optimize the
> *right* thing).
> 
> Dave

This is one thing I really lament about my uni education thus far.  Two
topics that basically have *never* been covered in even minimal detail
have been optimisation and debugging.

To be honest, I wouldn't know the most efficient way to return or pass
out a vector because I've never had any kind of grounding in the effects
of the various ways of doing it.  For instance: at what point does
passing by reference become faster than by value?

Wish I knew :)

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/