This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: return-value policy question
On Tue, Apr 29, 2003 at 01:15:57PM +0200, Gabriel Dos Reis wrote:
> Nathan Myers <ncm-nospam at cantrip dot org> writes:
>
> | In much of the library implementation I find code like that in
> | streambuf::sputc : ...
> | instead of the simpler and more elegant
>
> Frankly, I can't find in what the second version is simpler and more
> elegant.
It is indisputable, by Occam's Razor, that the latter is simpler:
it involves fewer elements. The questions were whether the extra
complexity in the former is (a) actually expensive and (b) worth
its weight.
> 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).
This is a question about small inline functions, not functions that
span many pages. It is clearly a matter of taste whether adding extra
variables makes the code easier to understand, but is not the issue.
Obviously when walking code in the debugger it is easier to look at
__ret than to figure out which register the compiler put the value in.
But at what cost?
> [...]
>
> | 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.
Likewise. Obviously the last is a little harder to read, but can
"-O" really be counted on to crush out the difference? Or is it
actually, objectively better to have a single instance of the return
sequence, and have other code to carry the value to it? This is code
that is called in inner loops, so small differences are multiplied.
I can read x86 code myself, but there are lots of different x86
targets with different pipeline characteristics, and lots of non-x86
targets. I'm asking for objective runtime effects of the choice --
or whether it's purely a matter of someone's taste.
Nathan Myers
ncm-nospam at cantrip dot org