Re: return-value policy question

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

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

| 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.

It is questionable and disputable whether your version of Occam's razor
has any relevance here:  Involving fewer "elements" does not necessarily
imply  "being simpler", witnesses the third version you proposed.


| > 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.

  1) Being declared inline does not necessarily means "being small"

  2) And if it is small as you're stating, then you should not have
     brought it here in the first place.

|  It is clearly a matter of taste whether adding extra 
| variables makes the code easier to understand, but is not the issue.

Surely the issue you raised boils down to that.  Disguising it into your
version of Occam's razor does not make that fact go away.

| 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?

And what cost do you see here?

| > [...]
| > 
| > | 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.

Do you any measurable difference?  If so, I would strongly suggest you
feel a GNAT PR against the compiler, not the library.

-- Gaby