Re: [C] return statement in void function?

From: Anthony Borla (ajborla_at_bigpond.com)
Date: 01/12/04 

Date: Mon, 12 Jan 2004 01:45:32 GMT

"Marlene Stebbins" <stebbins@email.com> wrote in message
news:400194E5.9040207@email.com...
>
> Should a function whose return value is declared void have a
> return statement. For example:
>
> void func(int * a)
> {
> *a *= 10;
> return; /* always, never, sometimes? */
> }
>

A function prototyped a returning 'void', meaning it doesn't return a value
to the calling function, does not require an explicit 'return' statement as
its use is implied - once execution hits the closing brace of the function
body [symbollically speaking, of course :)], a 'return' is effected. Hence:

    void f() {}

and this:

    void f() { return; }

are equivalent implementations

You may be interested to know that you can do this:

    void f() { return void(); }

as is this:

    void g() {}
    void h() { return g(); }

Yes, it may seem strange, but it is allowed [I suspect] to maintain
syntactic consistency.

The use of 'return' is allowed even from a constructor or destructor:

    class Void
    {
    public:
       Void() { return; }
       Void(int) {}
       ~Void() { return; }
    };

The explicit use of 'return' from a 'void' function [or even from a
constructor or destructor] can be useful where multiple function exit points
are required. While structured programming purists insist that a function be
designed to have a single entry and a single exit, this approach *can*
sometimes lead to quite cluttered code. An expeditious 'return' statement or
two can help to make code clearer in some cases because it allows you to
create an 'exit unless condition met' type of design - the function code
that does the bulk of the work is located toward the middle of the function
body, and will not be executed unless certain pre-conditions are met; it
looks something like this:

    void f()
    {
        if (!c) return;
        ...
        if (!d && e) return;
        ...
        ...
    }

Much the same reasoning is behind the use of 'break' to exit a loop.

The important thing is to be aware of what is possible, and the associated
costs / benefits. You, as the programmer, then intelligently decide whether
a particular technique / approach / style is appropriate in a particular
situation.

I hope this helps.

Anthony Borla

Relevant Pages