|
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
|
|
|
|
|
Sorry I was under the impression that
int fn(){
int a;
return(0);
} was K&R, the cooler
void fn
{
int a;
} I though one the rules was 'thou shalt return a value!'
Glenn 
|
|
|
|
|
In the C89 standard draft (the actual standard you have to buy).
Shows that return has never been required....minimalist approach...
https://port70.net/%7Ensz/c/c89/c89-draft.html#3.2.2.2
3.6.6.4 The return statement
...
Reaching the } that terminates a function is equivalent to executing a return statement without an expression.
|
|
|
|
|
mdblack98 wrote: Reaching the } that terminates a function is equivalent to executing a return statement without an expression.
My copy of the 1978 C reference manual contains the equivalent statement:
"Flowing off the end of a function is equivalent to a return with no returned value."
It also said that if 'return;' form is used, the returned value is undefined. The absence of a type declarator was assumed to mean 'int'. At that time there was no 'void' keyword. So, no need to search earlier than 1978 for the complete answer.
|
|
|
|
|
One of my first surprises (in the 90's) going from C++ to C, was that void was never used to define the return value of a main function. C++ had, at that point, always meant to be a superset of C and so had many odd things you wouldn't see in C for years (like variable declarations anywhere in the function).
My understanding was that C was always supposed to return a value to the operating system as an integer, regardless of what you did. So when C++ introduced void as a return type, even for main, I guess it was up in the air what you did in the end (that book has since been lost to a basement flooding so I can't remember or look up how it recommended to end the main function)
|
|
|
|
|
Juan Pablo Reyes Altamirano wrote: So when C++ introduced void as a return type, even for main
That statement is some what confusing as phrased.
Presumably originally C++ allowed for no return value from main(). Thus for compilation to succeed the type would need to be void.
That was because C allowed main to exit without a return value also.
The original C recommended a return value. And so does C++. Following is from "The C++ Programming Language Special Edition" section 6.1.5
"Conventionally, main() should return zero if the program terminates normally and nonzero otherwise."
And from 3.2
"If no value is returned, the system receive a value indicating successful completion"
So it is saying that the program doesn't need to but then a default value will be returned. So it is implicit.
|
|
|
|
|
Sorry to burst your bubble on dissing Pascal developers, but in Pascal you do not write void functions, it makes the sane distinction between functions (which return a value) and a procedure (which doesn't). 
|
|
|
|
|
A long way (below) to get to the short version of the answer: No, it was never required and quite on purpose!! C was sort of ALGOL like and to get around one of the most common mechanical errors in assembly language, we forced ALGOL like structure. Some of those errors in assembler came from multiple entry and exit points from subroutines (what we call typed and untyped functions in C). Having an explicit "return" instruction even in an untyped function in C allowed for multiple exits from a function but only *one* entry. This fixed a lot of errors we used to get in assembly language. My opinion is that this is a semi-reasonable thing to do in C. When K&R wrote their initial "White Book" (mostly good for toilet paper!), they intentionally made the closing brace the equivalent of an explicit "return();" or "return;" statement. Remember that C was written to replace assembler on a PDP-8 or PDP-11 from Digital Equipment Corp. Such a machine might have used dual 186 kilobyte 8 inch single sided floppy disks and have maybe 16kB of main memory. To that end, a lot of things like implicit "return" and other things were implemented to save bytes on those floppy disks when the source files were saved. Same reason original C only allowed significance of 6 character function and variable names!!!
Too Long; Didn't Read Version:
I have been programming in "C" since BSD Unix and System III Unix first came to be available in the wild. Pretty sure early HPUX was a BSD release and where I did most work. Your question as posed cannot be answered because C and C++ are totally different languages and I would go so far as to say "C++" has *never* been a language! Stroustrop *never* got a standard for the initial C++ and standards such as C++17 (not sure I have the number right) look *nothing* like the C++ "things" I used when first using the prototype language versions. My point: C++17 is *NOT* C++ but a separate newer and incompatible language with numerous upgrades, stupid ideas, mistakes, and other differences from C++ as described by Stroustrop in his book. I think I gave my copy of the book to Half Price Books when we downsized our house. It was not uncommon for some of those languages to *require* and explicit return statement or even to require *just one* exit from a function. In some languages, an "untyped function" was instead called a "procedure". Just semantics... Now we have compilers with type checking and *many* other mechanical aids to make arguably correct code that we couldn't do in the 80s.
So, now that history lesson is over, I'll answer your question for C only from a 45 or so year perspective. The 1980's were a time when we in the business were struggling with ways to mechanically make sure our code was correct and error free. It spawned a *LOT* of languages designed for just that goal: Modula2, Pascal, Ada, PLM86, Pascal86, TurboPascal, PLM, etc. Most were based on ALGOL. A lot of those languages didn't ever make it to both microcomputers (remember when we had 65536 bytes of RAM and as much as 128k couldn't even be accessed) or to Unix. Much *real* code was being done in native assembly language, FORTRAN, or COBOL!!!! My ex-wife spent an entire 30 year career writing COBOL. DuPont ran entire chemical plants in the 80s on PDP-11s with 10s of thousands of lines written in FORTRAN.
In C (and to a small extent C++), the "return()" statement or the end brace, restores the previous stack pointers and then pops the address of the calling subroutine as part of executing the assembly language return from subroutine instruction. If you turn off optimization, the following code generates *2* rts instructions with one of those being dead code that can never be executed!
void test_program(void)
{
return;
}
test_program:
; set up the function stack as part of opening curly brace
push sp;
; return statement
pop sp;
rts;
; ending curly brace
pop sp;
rts;
; end of function
|
|
|
|
|
Early c-compilers could only return values but not expressions.
(this was a design flaw of the compiler/c language)
{
int x;
x = 42;
return x; return x + 1; return(x + 1);
This is why you see the return statement so often together with parentheses even when they aren't required anymore.
You should NOT write these unnesseccary parentheses anymore!
The return statement is not a function call; just omit the parentheses.
|
|
|
|
|
sx2008 wrote: You should NOT write these unnesseccary parentheses anymore!
I disagree.
You can write a C program on one line by removing those unnecessary end of line characters but that is not a good idea either.
sx2008 wrote: The return statement is not a function call; just omit the parentheses.
Far as I know no one ever claimed it was.
|
|
|
|
|
ReTuRn("December"); return("December");
Don't make a return statement look like a function call.
Quote: You can write a C program on one line by removing those unnecessary end of line characters but that is not a good idea either.
Yes, but it makes the code less readable.
Changing return("December"); to return "December"; improves the readability.
You may argue it doesn't make a difference, but it does.
Your Brain needs a little more power to decode the text on the screen.
(Even the C-compiler needs some microseconds more)
It's a good exercise for a developer to go down the rabbit hole...
return ((((0)))); return ((0)); return 0;
|
|
|
|
|
Calling for STM32 microcontrollers firmware folks.
Based on your experiences, could you please suggest a good alternative to STM32CubeIDE ?
I don't dislike it, but it is very heavy-weight.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Keil [^] and IAR [^].
Both have free versions, of course with restrictions.
As the aircraft designer said, "Simplicate and add lightness".
PartsBin an Electronics Part Organizer - Release Version 1.3.0 JaxCoder.com
Latest Article: SimpleWizardUpdate
|
|
|
|
|
Thank you, Mike.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I forgot about Keil. Thanks.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I don't know of an IDE that replaces it, though I'd like one because Cube simply does not work properly on my machine.
I use Zephyr anyway though. It's a bit of a steep learning curve, but flexible once you get your project set up.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Quote: I use Zephyr anyway though. It's a bit of a steep learning curve
So you have to write an article about (kidding).
Thank you!
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I did, although even with the article it's not easy.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
CListCtrl with the Liquid Nitrogen add-on!
veni bibi saltavi
|
|
|
|
|
Of course! 
It's been a while, how do you do?
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
A couple of days ago, I posted a thread to this forum asking you what your most valuable life skill[^] is. You guys responded with many great comments. I found them interesting and thought-provoking. Thank you for that. I'm taking some time to share my knowledge with you in hopes that you may benefit as well.
Of all the responses, the one that resonated with me most was posted by @JeremyFalcon
You can view his post here: A Link to Post[^]
In summary, he stated his most important life skill is to know how to read people. I think such a skill has great value. I say that because it is such a fundamental concept.
I'll start by using an analogy. Would you suppose it's possible to understand computational science without the understanding of boolean logic? Boolean logic is a fundamental concept upon which all computer technology is based.
Is it possible to understand other people if you don't first understand yourself? This is the basis for my belief in what I think are the most important skills in my life.
These skills span several different categories of knowledge. Most of this knowledge is derived from philosophy and psychology. Philosophy can provide an understanding of formal logic. Formal logic is the basis for critical thinking. Critical thinking enables you to reason properly. If you don't reason properly, your thinking is distorted. Distorted thinking creates distorted beliefs. Beliefs determine your behavior. Your behavior determines who you are as a person. Who you are as a person determines your quality of life. Good quality of life is something I think we can all consider to be important, right? I think so.
The most fundamental aspect supporting this knowledge can be demonstrated by evolution and biology. What do all living organisms share in common? The most fundamental instincts of any organism, from bacteria to mankind are firstly procreation, and secondly survival. If you understand this fundamental knowledge, then you understand the basis of human nature.
Pay close attention to your thought process. Pay attention to your emotions. Analyze your reasoning by using formal logic. Use critical thinking to question your beliefs. Pay attention to the emotion behind your thoughts, and pay attention to thoughts and the emotions they invoke.
There are many types of distorted thinking, and everyone has distorted thoughts. In order to correct these distortions, we must identify them. In psychology, there's a concept known as cognitive behavioral therapy (CBT). In short, it's the process of identifying and correcting cognitive distortions. You only need to be familiar with only a dozen of these thought distortions. For the sake of time, I'll provide a link to Google search results that explain these distortions in thinking. Thought Fallacies CBT - Google Search[^]
I've spent a lifetime and thousands of hours studying these areas of knowledge. I use the skills I've developed from this in everything I do. They are universally applicable. They are the most essential skills I have, by far. I don't want to even imagine how awful life would be without knowing this stuff.
I could write a book on this, but this post is just a short summary. You don't need to believe what I say. If you think I'm a tool, you have the right to do so. You can disagree with what I'm saying. You have the right to question it and provide counterarguments. I'm simply hoping that my lengthy post can provide you with some of the knowledge that I have found to be priceless.
|
|
|
|
|
Steve Raw wrote: Would you suppose it's possible to understand computational science without the understanding of boolean logic?
Yes.
Boolean logic is actually a formal study. One can learn some basics without going into depth. One can also learn the basics without even understanding that it is Boolean logic.
Steve Raw wrote: In order to correct these distortions, we must identify them. In psychology, there's a concept known as cognitive behavioral therapy (CBT). In short, it's the process of identifying and correcting cognitive distortions.
First of course humans are not computers. Attempting to break down humans into measurable components is only remarkable in how many different ways have been tried and failed. Despite claims of success by the practitioners.
Lot of psychology is nonsense. Unfortunately originating on the utter nonsense of Freud and Jung. Pretty sure that CBT falls into that category as well. At least in general. There might be very specific areas that might provide some benefit. Perhaps in treating phobias. But figuring that out with objective criteria is probably not easy.
Steve Raw wrote: I don't want to even imagine how awful life would be without knowing this stuff.
Just noting that many people do not do any of this. And they seem to be quite happy.
In contrast many people try to fix themselves by spending vast amounts of time (and money) and yet never succeed.
So myself I expect that the process that you followed is not what actually lead to success. But rather something in you, not learned, which might or might not have been helped by the process.
One could ask how do you objectively measure your success? How do you know that something completely different would not have had the same result? Or with no process would you have not reached the same point (studies on talk therapy have this problem.)
|
|
|
|
|
Thank you for taking the time to read this. I'm glad to hear what you have to say, regardless of whether you disagree, or not.
|
|
|
|
|
I am I. Mission accomplished. Hopefully, you are you.
|
|
|
|
|
David O'Neil wrote: I am I. Mission accomplished. Hopefully, you are you.
I think maybe I am, therefore what am I?
I'd say that's the best I can do to realize my own existence. I've been on this rock for four decades and I have no idea what's going on.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
