( C/C++ historical question) was there a point in time where adding a return at the end of a void function was required ?
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
Was it necessary at some point in time ?
I would say no, but I can't answer it definitively. But in the 35 years I've been programming C++, I've never been forced to write a 'return' at the end of a void method. [Edit] Neither I have been forced (by some older compilers from Borland) to write a return even it was a 'non-void' method. Which ended usually in a desaster, especally when the return type was float or double :^) :laugh:
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
I think it was never required. However, someone wrote[^]:
If no return statement appears in a function definition, control automatically returns to the calling function after the last statement of the called function is executed. In this case, the return value of the called function is undefined. If the function has a return type other than void, it's a serious bug, and the compiler prints a warning diagnostic message. If the function has a void return type, this behavior is okay, but may be considered poor style. Use a plain return statement to make your intent clear.
Note, it's not me. I think omitting the
returnstatement in avoidfunction it is fine."In testa che avete, Signor di Ceprano?" -- Rigoletto
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
Had heard more than 20 years ago, that having a
returnstatement at the end of avoidfunction in C++ was indeed a harmless thing; the compiler wouldn't complain, and things would work just fine. Just that some programmers prefer to have areturnin every function they write. -
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
Maximilien wrote:
Was it necessary at some point in time ?
Necessary, no. Used, yes, back in the day probably because people were used mostly with FORTRAN where each function and "subroutine" needed at least one return statement.
Mircea
-
I think it was never required. However, someone wrote[^]:
If no return statement appears in a function definition, control automatically returns to the calling function after the last statement of the called function is executed. In this case, the return value of the called function is undefined. If the function has a return type other than void, it's a serious bug, and the compiler prints a warning diagnostic message. If the function has a void return type, this behavior is okay, but may be considered poor style. Use a plain return statement to make your intent clear.
Note, it's not me. I think omitting the
returnstatement in avoidfunction it is fine."In testa che avete, Signor di Ceprano?" -- Rigoletto
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
Maximilien wrote:
Was it necessary at some point in time ?
Both forms are specifically allowed then and now. From "C Programming Language" 2nd Edition (oldest I have and copyright is 1978.) "A function need not return a value; a return statement with no expression causes control, but no useful value, to be returned to the caller, as does "falling off the end" of a function by reaching the terminating right brace." Possible though that earlier compilers required it. More likely though that someone liked one form or the other. Perhaps even forced that on others. Requiring it would be fallout from methods with a return value. Older compilers would not warn on exit without a value for those. So the calling method would then end up with whatever garbage was on the call stack. I did not find the same syntax in "The C++ Programming Language Special Edition" (Copyright 2000) but I didn't look all that hard. There are however examples that provide two different void functions. One which exits with return and one which does not. So works for C++ also. ----------------------------------------------------- Just for fun this is LEGAL as documented in the C++ book above.
void g(int* p);
void h(int* p) { return g(p); }
Text explains that is needed for templates. But if I was reviewing code and saw that anywhere but a template I would mark it as an error.
-
Was it necessary at some point in time ?
I would say no, but I can't answer it definitively. But in the 35 years I've been programming C++, I've never been forced to write a 'return' at the end of a void method. [Edit] Neither I have been forced (by some older compilers from Borland) to write a return even it was a 'non-void' method. Which ended usually in a desaster, especally when the return type was float or double :^) :laugh:
I have a vague recollection that in K&R days, the value of a function was the value of the last executed statement. so
f(x)
int x;
{
x += 3;
}would return whatever x+3 evaluated to. I also seem to recall that a function return had to fit in a register. Not sure if either of those are correct. It was a long long time ago. But not in a galaxy far away.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
Unsure, maybe, C back in the 80s. Or Pascal? But I always make sure each and every C function (or C# Method) has exactly one return statement. (I think I've written only one C# Method with more than one return, but that was an unusual situation.) I agree that it "shows intent". Or potentially may help with debugging, though that's not usually critical either. At the very least you know that it was written by a developer who has a long history of development, not one of these kids who is only interested in doing the absolute minimum and can't be trusted.
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
I believe it never was, as it was meant to be more or less compatible with C code, which doesn't require it. Interestingly you can call main() from inside your C app, but not in C++.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Unsure, maybe, C back in the 80s. Or Pascal? But I always make sure each and every C function (or C# Method) has exactly one return statement. (I think I've written only one C# Method with more than one return, but that was an unusual situation.) I agree that it "shows intent". Or potentially may help with debugging, though that's not usually critical either. At the very least you know that it was written by a developer who has a long history of development, not one of these kids who is only interested in doing the absolute minimum and can't be trusted.
Quote:
But I always make sure each and every C function (or C# Method) has exactly one return statement.
I followed the same for nearly 30 years. Meanwhile I switched at least for 'void methods' to return imediatelly something does not fit. This to avoid 'nested if' Still I'm fighting with that when a method needs to return a value. Here I stay with the pattern to have only _one_ return.... :sigh:
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
I doubt the language ever required it, but maybe some “lint” programs had that as a setting? “Ensure there is at least one return statement for every function” It would help catch the undefined return value if you forgot the return statement. I could see a first generation lint program complaining of a missing return on a void function.
-
Maximilien wrote:
Was it necessary at some point in time ?
Both forms are specifically allowed then and now. From "C Programming Language" 2nd Edition (oldest I have and copyright is 1978.) "A function need not return a value; a return statement with no expression causes control, but no useful value, to be returned to the caller, as does "falling off the end" of a function by reaching the terminating right brace." Possible though that earlier compilers required it. More likely though that someone liked one form or the other. Perhaps even forced that on others. Requiring it would be fallout from methods with a return value. Older compilers would not warn on exit without a value for those. So the calling method would then end up with whatever garbage was on the call stack. I did not find the same syntax in "The C++ Programming Language Special Edition" (Copyright 2000) but I didn't look all that hard. There are however examples that provide two different void functions. One which exits with return and one which does not. So works for C++ also. ----------------------------------------------------- Just for fun this is LEGAL as documented in the C++ book above.
void g(int* p);
void h(int* p) { return g(p); }
Text explains that is needed for templates. But if I was reviewing code and saw that anywhere but a template I would mark it as an error.
jschell wrote:
Possible though that earlier compilers required it.
You remind me that my first introduction to C was with Whitesmith C (on a VAX), and maybe that could have required it.
-
Maximilien wrote:
Was it necessary at some point in time ?
Both forms are specifically allowed then and now. From "C Programming Language" 2nd Edition (oldest I have and copyright is 1978.) "A function need not return a value; a return statement with no expression causes control, but no useful value, to be returned to the caller, as does "falling off the end" of a function by reaching the terminating right brace." Possible though that earlier compilers required it. More likely though that someone liked one form or the other. Perhaps even forced that on others. Requiring it would be fallout from methods with a return value. Older compilers would not warn on exit without a value for those. So the calling method would then end up with whatever garbage was on the call stack. I did not find the same syntax in "The C++ Programming Language Special Edition" (Copyright 2000) but I didn't look all that hard. There are however examples that provide two different void functions. One which exits with return and one which does not. So works for C++ also. ----------------------------------------------------- Just for fun this is LEGAL as documented in the C++ book above.
void g(int* p);
void h(int* p) { return g(p); }
Text explains that is needed for templates. But if I was reviewing code and saw that anywhere but a template I would mark it as an error.
jschell wrote:
void h(int* p) { return g(p); }
Yuck. That's deceptive to me, as it makes it look like
g(p)returns a value. I'd prefer writing it like this:void h(int* p)
{
g(p);
return; // if you really feel the need
}Software Zen:
delete this; -
I believe it never was, as it was meant to be more or less compatible with C code, which doesn't require it. Interestingly you can call main() from inside your C app, but not in C++.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
Interestingly you can call main() from inside your C app, but not in C++.
Really? I didn't know that. I'll admit it's probably not a good idea, and there are easy ways around the prohibition, ... Hmm. I think I've figured some of it out.
- There are multiple valid forms of
main(...), and implementation-defined arguments are allowed. Allowing calls to it might require too much special case handling between the compiler and linker to ensure a match between the call and the actual implementation. - Another factor might be runtime initialization that takes place in
main()'s prolog. - Objects declared
staticcould potentially callmain()before it had been called for the actual application startup. X|
Sounds like the prohibition is a good way to make the compiler, linker, and runtime initialization job easier.
Software Zen:
delete this; - There are multiple valid forms of
-
honey the codewitch wrote:
Interestingly you can call main() from inside your C app, but not in C++.
Really? I didn't know that. I'll admit it's probably not a good idea, and there are easy ways around the prohibition, ... Hmm. I think I've figured some of it out.
- There are multiple valid forms of
main(...), and implementation-defined arguments are allowed. Allowing calls to it might require too much special case handling between the compiler and linker to ensure a match between the call and the actual implementation. - Another factor might be runtime initialization that takes place in
main()'s prolog. - Objects declared
staticcould potentially callmain()before it had been called for the actual application startup. X|
Sounds like the prohibition is a good way to make the compiler, linker, and runtime initialization job easier.
Software Zen:
delete this;Part of it might be static initialization behavior in C++ precludes it, but I don't know enough about the machinations of all that to be certain of anything.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
- There are multiple valid forms of
-
I believe it never was, as it was meant to be more or less compatible with C code, which doesn't require it. Interestingly you can call main() from inside your C app, but not in C++.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
This piece of code
int main()
{
main();
}compiles fine. Anyway, I didn't try to run the executable. :laugh:
"In testa che avete, Signor di Ceprano?" -- Rigoletto
Hmm, well I've never actually tried it. I was relying on a lecture on C++. I doubt it's standard though. I'm pretty sure dude knew what he was on about. He wasn't a nobody, but I forget his title.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I see a lot of things like this in the project I'm working on: Was it necessary at some point in time ? Was this an ancient C syntax ?
void f(){
// .... do something
return;
}I would not be surprised if I see old K&R syntax somewhere like this
void f( a )
int a
{
}CI/CD = Continuous Impediment/Continuous Despair
Maybe it's tag that has meaning only to the "creator". Mine are leftovers from extending a function then changing my mind.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Hmm, well I've never actually tried it. I was relying on a lecture on C++. I doubt it's standard though. I'm pretty sure dude knew what he was on about. He wasn't a nobody, but I forget his title.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
It looks 'the dude' was right. The C++ standard doesn't allow to call main recursively (and states that main 'shall not be used within a program'). Nevertheless, g++ allows that. You have to use -pedantic in order to get a warning.
"In testa che avete, Signor di Ceprano?" -- Rigoletto