Re: return-value policy question

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Nathan Myers <ncm-nospam at cantrip dot org> writes:

| In much of the library implementation I find code like that in
| streambuf::sputc :
| 
|       int_type __ret;
|       if (_M_out_cur < _M_out_end)
|         {
|           *_M_out_cur = __c;
|           _M_move_out_cur(1);
|           __ret = traits_type::to_int_type(__c);
|         }
|       else
|         __ret = this->overflow(traits_type::to_int_type(__c));
|       return __ret;
| 
| instead of the simpler and more elegant

Frankly, I can't find in what the second version is simpler and more
elegant.  The former compute the value to return in either branches,
and in a single return-statement returns the computed value.  

Having -- recently -- to monitor return-statements in the compiler I
found it  

  * astonishingly helfpul that functions that span may pages have a
    single return statement and very easy to monitor;

  * functions that had many return-statements were the ones that
    provided many opportunities for having the auditing worng;

  * the functions with a single return-statement are no harder to
    read (actually it was the functions with many return-statements
    that were harder to read).

[...]

| or the even simpler and more traditional
| 
|       return (_M_out_cur < _M_out_end) ?
|         traits_type::to_int_type(*_M_out_cur++ = __c) :

I find such an assignment a good candiate for obfuscations, not for
clarifications. 

-- Gaby