Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #20657 > unrolled thread

Redundant return()

Back to article view | Back to comp.lang.c

Contents

  Redundant return() pembed2012 <once@was.enough.invalid> - 2012-05-12 21:41 +0000
    Re: Redundant return() pembed2012 <once@was.enough.invalid> - 2012-05-12 21:56 +0000
      Re: Redundant return() Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-05-12 17:07 -0600
    Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-12 18:46 -0400
      Re: Redundant return() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-12 20:10 -0400
        Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-12 21:29 -0400
    Re: Redundant return() Barry Schwarz <schwarzb@dqel.com> - 2012-05-12 15:49 -0700
      Re: Redundant return() pembed2012 <once@was.enough.invalid> - 2012-05-14 16:40 +0000
        Re: Redundant return() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-14 17:57 +0100
        Re: Redundant return() nick_keighley_nospam@hotmail.com - 2012-05-15 00:33 -0700
          Re: Redundant return() nick_keighley_nospam@hotmail.com - 2012-05-15 03:03 -0700
            Re: Redundant return() nick_keighley_nospam@hotmail.com - 2012-05-15 03:26 -0700
            Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-15 08:51 -0400
          Re: Redundant return() "BartC" <bc@freeuk.com> - 2012-05-15 12:20 +0100
            Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 07:59 +1200
              Re: Redundant return() Kaz Kylheku <kaz@kylheku.com> - 2012-05-15 20:08 +0000
                Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 08:18 +1200
                  Re: Redundant return() Lanarcam <lanarcam1@yahoo.fr> - 2012-05-15 22:48 +0200
                    Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 09:56 +1200
              Re: Redundant return() "BartC" <bc@freeuk.com> - 2012-05-15 22:59 +0100
                Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 10:16 +1200
                  Re: Redundant return() "BartC" <bc@freeuk.com> - 2012-05-16 09:29 +0100
          Re: Redundant return() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-15 07:51 -0400
          Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-15 08:47 -0400
            Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 08:01 +1200
            Re: Redundant return() "BartC" <bc@freeuk.com> - 2012-05-15 22:58 +0100
              Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 10:24 +1200
                Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-15 18:39 -0400
                Re: Redundant return() nick_keighley_nospam@hotmail.com - 2012-05-16 02:45 -0700
    Re: Redundant return() Noob <root@127.0.0.1> - 2012-05-16 13:34 +0200

Page 2 of 2 — ← Prev page 1 [2]

#20834

On 05/16/12 09:59 AM, BartC wrote:
>
>
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:a1fqsoFd96U1@mid.individual.net...
>> On 05/15/12 11:20 PM, BartC wrote:
>>> "Stefan Ram"<ram@zedat.fu-berlin.de>   wrote:
>>>
>>>>    If it is complex, we put it into a function »f«, so:
>>>
>>> But the body of f() will still be complex (as you've only eliminated a
>>> couple of lines; it that now makes it simple, then it was *not*
>>> complex!);
>>> then what? Suppose there were several such returns in a function? You
>>> would
>>> end up *increasing* complexity (by extra functions, extra names, extra
>>> interfaces) for no discernible benefit. Actually it would be probably be
>>> slower, less readable, and more buggy.
>>
>> Testing.  A large, complex, function is hard to test.  More less complex
>> functions are easier to test.
>
> I don't see that. You're testing inputs and outputs. A function which is
> 'complex' in the amount of logic it contains, can still have simple
> requirements and be straightforward to test.

But if you change something and break the function, a swag of tests will 
fail and you then have to work out why (or back out the edit).

> But one which is arbitrarily broken up into pieces, now needs to have a
> meaningful set of specifications drawn up for each part.

Who mentioned arbitrarily?  The tests *are* the specification.

>> That's why code written test first won't contain large, complex,
>> functions.
>
> That's right; you build a framework of one hundred functions, all initially
> empty (or with some stub).

No.

> They each do ten different things depending on
> some parameter. Each of those things is straightforward by itself, but can
> be added one by one, function by function. In the end you have 5000
> different things split amongst 100 functions.

No.

> Your way, there would be 5000 2-line functions. Plus 100 dispatcher
> functions.

No.

> And most of the relationships amongst each group of ten, has
> disappeared.

My typical function size is 10-20 lines.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#20848

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:a1g2t5Fd96U6@mid.individual.net...
> On 05/16/12 09:59 AM, BartC wrote:

>> They each do ten different things depending on
>> some parameter. Each of those things is straightforward by itself, but 
>> can
>> be added one by one, function by function. In the end you have 5000
>> different things split amongst 100 functions.
>
> No.

Well, you're right in that you end up with 1000 things not 5000...

>> And most of the relationships amongst each group of ten, has
>> disappeared.
>
> My typical function size is 10-20 lines.

My average is around 40 (except for projects where large numbers of small 
functions are used deliberately, but are managed semi-automatically, usually 
involving tables of function pointers).

That average fits in well with the size of my editor window, around 60 
lines.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#20800

On 5/15/2012 3:51 AM, Stefan Ram wrote:
>> On Monday, May 14, 2012 5:40:34 PM UTC+1, pembed2012 wrote:
>>> Ho, you are right, I can invoke the return function with no () and there
>>> is no compiler error. Wired.
>
>    The supposed spelling is »wierd«.

     Skitt's Law has weird consequences.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#20802

On 05/15/2012 03:51 AM, Stefan Ram wrote:
>> On Monday, May 14, 2012 5:40:34 PM UTC+1, pembed2012 wrote:
>>> Ho, you are right, I can invoke the return function with no () and there 
>>> is no compiler error. Wired.
> 
>   The supposed spelling is �wierd�.
> 
> nick_keighley_nospam@hotmail.com writes:
>> some odd misconceptions. An early return can be handy.
> 
>   �handy� is vague wording.
> 
>> if (log == NULL)
>>    return;
>> /* complex processing */
> 
>   If it is complex, we put it into a function �f�, so:
> 
> if( log ){ f(); fprintf( log, "LOG: %s\n", msg ); }
> 
>   . The real reason for an early return as in
> 
> while( ... )
> { ...
>   if( ... )return result;
>   ... }
> 
>   is that tests have shown that this often executes faster
>   than a single exit.

Any decent modern compiler should generate the same code either way, so
if it does run noticeably faster using one approach, then you should get
a better compiler.

The relevant issue isn't speed, but ease of comprehension. Supporters of
"single exit" claim it's easier to comprehend; my personal experience is
that early-return is easier.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#20818

On 05/16/12 12:47 AM, James Kuyper wrote:

> The relevant issue isn't speed, but ease of comprehension. Supporters of
> "single exit" claim it's easier to comprehend; my personal experience is
> that early-return is easier.

Especially when you see some of the goto spaghetti some single exit 
functions end up using!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#20830

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:jotj8p$2j5$1@dont-email.me...
> On 05/15/2012 03:51 AM, Stefan Ram wrote:


>>   is that tests have shown that this often executes faster
>>   than a single exit.
>
> Any decent modern compiler should generate the same code either way, so
> if it does run noticeably faster using one approach, then you should get
> a better compiler.
>
> The relevant issue isn't speed, but ease of comprehension. Supporters of
> "single exit" claim it's easier to comprehend; my personal experience is
> that early-return is easier.

Yes. Easier in that there is then a choice.

I can't see the problem with multiple returns. No matter how many returns 
there are in one function, the next statement executed will always be the 
one falling the original call. That's not much different from 'single exit'.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#20835

On 05/16/12 09:58 AM, BartC wrote:
> "James Kuyper"<jameskuyper@verizon.net>  wrote in message
> news:jotj8p$2j5$1@dont-email.me...
>> On 05/15/2012 03:51 AM, Stefan Ram wrote:
>
>
>>>    is that tests have shown that this often executes faster
>>>    than a single exit.
>>
>> Any decent modern compiler should generate the same code either way, so
>> if it does run noticeably faster using one approach, then you should get
>> a better compiler.
>>
>> The relevant issue isn't speed, but ease of comprehension. Supporters of
>> "single exit" claim it's easier to comprehend; my personal experience is
>> that early-return is easier.
>
> Yes. Easier in that there is then a choice.
>
> I can't see the problem with multiple returns. No matter how many returns
> there are in one function, the next statement executed will always be the
> one falling the original call. That's not much different from 'single exit'.

Clean-up is always the elephant in the room with multiple returns in C. 
  Hence the proliferation of goto spaghetti.  I for one prefer early 
return on precondition tests, but once a function allocates a resource 
or changes a state, there should only be one.

Multiple returns are more common (and banning them unnecessary) in 
languages that have support for automatic clean-up.

All safety (as in user) focused C coding standards I have seen specify a 
single return.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#20837

On 05/15/2012 06:24 PM, Ian Collins wrote:
> On 05/16/12 09:58 AM, BartC wrote:
>> "James Kuyper"<jameskuyper@verizon.net>  wrote in message
>> news:jotj8p$2j5$1@dont-email.me...
...
>>> The relevant issue isn't speed, but ease of comprehension. Supporters of
>>> "single exit" claim it's easier to comprehend; my personal experience is
>>> that early-return is easier.
>>
>> Yes. Easier in that there is then a choice.
>>
>> I can't see the problem with multiple returns. No matter how many returns
>> there are in one function, the next statement executed will always be the
>> one falling the original call. That's not much different from 'single exit'.
> 
> Clean-up is always the elephant in the room with multiple returns in C. 
>   Hence the proliferation of goto spaghetti.  I for one prefer early 
> return on precondition tests, but once a function allocates a resource 
> or changes a state, there should only be one.

I'm in perfect agreement here. If I allocate memory, I normally use the
following structure where possible (there's obviously situations in
which it's NOT possible):

retval = SUCCESS;

p = malloc(count * sizeof *p);
if (p == NULL)
{
    // error handling
    return ERROR1;
}
else
{
    // Normal processing. 'return' prohibited in this block.

    if(error condition)
    {
        // other error handling
        retval = ERROR2;
    }

    free(p);
}

return retval;


I handle fopen() and fclose() similarly, and any other similar book-end
functions (the libraries I use have quite a few book-end pairs).

This approach doesn't scale well when many different resources need to
be managed simultaneously, in which case more complicated approaches are
needed.

[toc] | [prev] | [next] | [standalone]

#20849

On Tuesday, May 15, 2012 11:24:48 PM UTC+1, Ian Collins wrote:
> On 05/16/12 09:58 AM, BartC wrote:
> > "James Kuyper"<jameskuyper@verizon.net>  wrote in message
> > news:jotj8p$2j5$1@dont-email.me...

<snip>

> >> [...] Supporters of
> >> "single exit" claim it's easier to comprehend; my personal experience is
> >> that early-return is easier.

yes but to a certain degree this is a matter of taste.

> > Yes. Easier in that there is then a choice.
> >
> > I can't see the problem with multiple returns. No matter how many returns
> > there are in one function, the next statement executed will always be the
> > one falling the original call. That's not much different from 'single exit'.
> 
> Clean-up is always the elephant in the room with multiple returns in C. 

yes.

>   Hence the proliferation of goto spaghetti.  I for one prefer early 
> return on precondition tests, but once a function allocates a resource 
> or changes a state, there should only be one.

yes. Sounds pretty sensible

> Multiple returns are more common (and banning them unnecessary) in 
> languages that have support for automatic clean-up.

yes. With C++ you return or throw whenever you like- if you've RAIIed

> All safety (as in user) focused C coding standards I have seen specify a 
> single return.

[toc] | [prev] | [next] | [standalone]

#20855

Stefan Ram wrote:

> pembed2012 wrote:
>> I have seen redundant return statements at the end of function. IE.
>>        init_function()
>>        {
>>                a_init();
>>                b_init();
>>                c_init();
>>                return();
>>        }
> 
>   There is no return statement above.
> 
>   i.e. = id est (that is)
>   IE = internet explorer

Moreover, he (mis)used "i.e." instead of "e.g." (exempli gratia,
"for the sake of an example").

http://en.wiktionary.org/wiki/e.g.
http://en.wiktionary.org/wiki/i.e.

Regards.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web