what is the logical meaning of (return;)

[shahera.arafat]

hii :)
I've seen alot in (void)func. that at the end of it they put (return;)
why they put it ??what is the logical meaning of it ?? is it the same as (return0;) ??
actually it confused me alot :/
thanks ^_^

[Lerner]

It means "don't return anything". Similar to empty parameter brackets when declaring/calling functions. It can make code easier to read, particularly if you get into the habit of using only one return statement per function.

[AndrisP]

void is no returns but can change input params e.g.

#include <iostream>
#include <stdio.h>

void myfunc(int &a, int &b, int &c){
    a += 1;
    b -= 2;
    c = a+b;
    return;
    }

int main(){
    int a=5,b=6,c=7;
    // print before myfunc()
    printf("a=%d b=%d c=%d \n", a,b,c);

    myfunc(a, b, c);

    // print after myfunc()
    printf("a=%d b=%d c=%d \n", a,b,c);
    return 0;
    }

result of next example will be identical

#include <iostream>
#include <stdio.h>

void myfunc(int &a, int &b, int &c){
    printf("a=%d b=%d c=%d \n", a,b,c);
    a += 1;
    b -= 2;
    c = a+b;
    printf("a=%d b=%d c=%d \n", a,b,c);
    return;
    }

int main(){
    int a=5,b=6,c=7;
    myfunc(a, b, c);
    return 0;
    }

[deceptikon]

why they put it ??

They're being explicit, I suppose. If a function returns void, there's no need to place a return at the end. Falling off the closing brace does it automagically.

what is the logical meaning of it ??

It means that the function will hand execution back to the calling function, but return no value.

is it the same as (return0;) ??

No. return 0; does return a value, and cannot be used in a function with a return type of void.

[ddanbe]

Simply said: return is needed to tell your program to return to the place where it was, before this function was called.
But I agree with deceptikon, that a closing brace could do this trick equaly well. It depend on the compiler designers I guess.

[deceptikon]

It depend on the compiler designers I guess.

Language designers, rather. Allowing no return statement at the end of a function returning void is a hard rule in C++ that all compilers must adhere to.

Some programmers like to be explicit though, and always include a return statement regardless of what's allowed. One example is main. Despite returning int, a special rule states that you can omit a return statement and it will have the same effect as return 0;. Not everybody likes that rule because it's very niche and feels like an exception (only applies to main) that can cause confusion, so they always use a return statement.

I say, whatever floats your boat. Both are perfectly valid and acceptable. It boils down to personal preference. :)

[mike_2000_17]

I somewhat fall under that category. I like to be explicit about the end of the function with a return;. Part of this reason is that sometimes when writing several functions at the same time, or when you're writing one function and than split up some code into another, and write that one first, and then come back to the "higher" function that you were writing before. Well, when I do that, I kind of use the return; statement as a kind of marker of "this one is finished". So, I have a bit of a tendency to assume that if I see that one of my functions does not have a return; at the end, then it might be a function that I forgot to implement completely.

But like deceptikon said, to each his own. Every developer develops some quirks like that over the years, and sometimes the root causes of them are more or less rational, and sometimes historical. Some are bad habits that should be broken (like declaring all your local variables at the start), and others are just irrelevant (like this one, or another common one, that I also do, is putting a ; at the end of everything, even when it's not necessary (like after most closing braces)). There isn't much point to debating those quirks, but you need to be aware of them (so that you don't misinterpret) and know in whose ballpark you're playing.

In other words, if you are writing code for a project that contains some of these quirks, it's considered good manners to reproduce those quirks, even if you find them a bit stupid. For instance, I'm currently writing code for LLVM / Clang, which has lots of quirks that annoy me very much, but I abide. Usually, the maintainers and main developers in a project have their quirks and are attached to them (which is good in the sense of keeping things consistent in the code), and they'll get annoyed and frustrated if you contribute code that they either have to trivially revise to apply their style preferences to it, or that they later stumble upon and find distasteful (it's like you're dressing up their baby in ugly clothes).

[L7Sqr]

OT: I'm curious, mike_2000_17, what is it about the LLVM codebase that annoys you? I've have the opposite experience - adopting some of the style I found there.

[mike_2000_17]

what is it about the LLVM codebase that annoys you?

Here are a few things that I've encountered a lot in LLVM / Clang that irritate me (to varying degrees):

• ; characters after } only where it's needed.
• Intentionally using parameter names that conflict with data members (which are invoked with this->), apparently for "clarity" (I tend to prefer some artefact on parameters (usually a "a" prefix), it's the only place I use such Hungarian-style prefixes).
• No indentation of switch cases (I've seen real bugs created by this confusing style).
• No const-correctness whatsoever (that's probably the most serious one).
• False globals (i.e., when you're more concerned about appearing not to be using global variables, you just end up hiding them in convoluted syntactic constructs).
• Relying on code-generators for things that are trivially accomplished with the pre-processor.
• 80 character limit, which I think is excessive and antiquated (I prefer 120).
• CamelCase!
• .. and no_camel_case...
• if ( foo ) instead of if( foo ).
• if ( Foo *foo = get_some_ptr() ) (clever... maybe, but unavoidably inconsistent).
• Using Foo &foo, because everyone knows that a type modifier should be stuck to the object, not the type.. euh... whatever.
• I've also spotted some non-capitalized MACROs.
• Raw pointers everywhere instead of references.
• Error-codes, no exceptions (because you cannot use references, if you forbid exceptions).
• No RAII (I guess it's a good thing they don't use exceptions!).
• Virtually inexistent documentation.
• Make-up-as-you-go interfaces (tons and tons of half-complete interfaces).
• .... I guess what sums up their coding guidelines and styles is: multiple personality disorder.

I don't mean to disparage the LLVM / Clang folks (because many of those issues are secondary, and don't diminish the praise they deserve overall), but coding in there really feels like living in the dark ages of C++ (which I don't have any fond memories of, except maybe building character and resilience). I'm used to seeing code like that, from code-bases that were mostly developed in the 90s, and have been more or less inactive for 10 years. I don't expect that from a contemporary and active code-base like LLVM/Clang. Btw, LLVM is far better than Clang.