Why wont this code work

Code:

---

#include <iostream>
#include <fstream>

using namespace std;

int main

{
   
   
    Cout<<"opening file";
 
    ofstream a_file("file i want to open.txt", ios::app);
}

---

Also when compiling it give the error invalid function declration for {

Code:

---

#include <iostream>
#include <fstream>

using namespace std;

int main()
{
    cout<<"opening file"; // C++ is case sensitive.
 
    ofstream a_file("file i want to open.txt", ios::app);

    a_file.close();
    return 0;
}

---

Oh thank you

Code:

---

    a_file.close();

---

Not necessary. The destructor does that automatically.

Code:

---

    return 0;

---

Also not necessary. Implicit in C++.

Good practice though. Helps to understand what's going on.

I disagree, especially concerning the destructor. Part of being a C++ programmer is understanding when destructors are called and what they are supposed to do.

return 0, however, I think should be explicit.

> return 0, however, I think should be explicit.

I think it's safer in C++ to use the implicit return, since at least 95% of the time 0 is the desired value, and making it explicit runs the risk of getting it wrong (typo, or if someone gets confused and thinks 1 is the normal return value, since true and false correspond to 1 and 0, resp.). The only danger I see is if someone gets C and C++ confused and starts doing the same thing in C (unless it's C99-only code which is unlikely at this time).

> I think it's safer in C++ to use the implicit return, since at least 95% of the time 0 is the desired value
Whereas I think for the sake of 10 key presses (in what, thousands or millions), saying what you really mean is better. C++ removes a lot of implicit behaviour, then they add this horror.
Plus, it's a trick which only works with main. Try it with a function of your own, and it will complain.


IMO, this is a "sop" feature to allow all those void main programmers to change 'void' to 'int' and have a compliant program (like that's their only mistake), without having to trouble their poor little fingers into going to the other end of the function to type 'return 0;'.

The alternatives to the implicit return 0 would be either to 1) do what C90 does and not require an explicit return at the closing brace, meaning the possibility of an undefined return value - very bad - or 2) require an explicit return at the closing brace, but the problem with this is that the programmer might know that the closing brace is never reached and hence that the explicit return isn't needed, but the compiler can't figure it out. The implicit return means that the programmer never needs to write an explicit return that he knows isn't needed, but the compiler throws it in implicitly and guarantees there is never an undefined return value. At least I'm guessing that was the thought process behind it.

Edit: Unfortunately this reasoning only works for main(), where there is a reasonable default return value, and void functions, which don't have one - for other functions which return a value, the compiler can't insist on a return statement at the closing brace if it doesn't know it's possible for it to be reached, and can't throw in a default return, since in general there isn't a reasonable default value.

> 1) do what C90 does and not require an explicit return at the closing brace,
That would be bad. Simply generate a diagnostic and move on.

But that would presume that "falling off the end of main" was a "good thing" worthy of returning "success" to the environment.

> The implicit return means that the programmer never needs to write an explicit return
> that he knows isn't needed,
But surely in this case, the unexpected return (from one which cannot be reached apparently) would be more indicative of an error than success.

Like a void main programmer "knows", that's a good one ;)

If it were explicitly required, it would at least force the programmer to think about the problem rather than merely thinking "ooh, one less error, moving on to the next".

Quote:

---

Originally Posted by robatino

1) do what C90 does and not require an explicit return at the closing brace, meaning the possibility of an undefined return value - very bad -

---

I think this is the best option, considering the "You don't pay for what you don't use" idiom, which is generally valued above safety, like in the case of pointers. The implied return 0 means that every program that a compiler thinks may get to the end of main must have one extra instruction, even if the programmer or a better compiler can prove that the end of main can never be reached. Sure it's only one instruction, but it's the principles that matter. Does C++ value safety or executable size more?

Also, undefined behavior when you run at the end of main would allow a debugging compiler to know that an error occurred. A debug build may issue a runtime error when the end of main or any non-void function is reached. But if reaching the end of main is perfectly defined, then a debugger cannot and will not issue an error, even if the programmer intended that reaching the end of main be impossible.

BTW, the issue with no defined behavior when the end of main is reached is not that the return value is undefined. An undefined return value can actually be a good thing, because chances are the value will be non-zero, signifying correctly that an error has occurred. The issue is that the program may not know to return in the first place. It may continue to try to execute instructions that are not part of main.

ok I have 3 things to say

1. I agree it is good practice
2. I think this is a realy petty argument
3. get another thread this thread is being stolen form it's owner

Quote:

---

Originally Posted by h3ckf1r3

3. get another thread this thread is being stolen form it's owner

---

And you are not a moderator and you do not have a say in ordering everyone to stop.
Though you can, however, add that you think the thread is being stolen from the OP and perhaps it would be best to discuss elsewhere.
Then again, if a moderator sees fit, this thread could simply be split. And also then again, perhaps the OP leans something from the discussion.

As for the whole return thing...
One instruction more or less doesn't bloat the executable. Besides, the compiler adds return 0 implicitly anyway, so that argument is void.
Safe against typos is also a pretty poor argument.
And then we have the last thing - there are no defined return values. Different programs use different return values to specify error or success or whatever. In some apps, 1 may be the success value rather than 0. It's all up to the programmer and if it is a CLI-type app, then whomever is reading is had better read the doc on what the return values mean.
Therefore I also think that return values should be explicit. It must be explicit for any other function (exception for multiple return paths), so why not main?

> 3. get another thread this thread is being stolen form it's owner

Well, the OP had their problem solved in comment #2, so they can just ignore the rest of the thread if they want.

Does anyone know what the thought process was at the Standards Committee regarding the implicit return 0? I googled a bit but couldn't find anything.

ok sorry if it seemed like a command it just was a comment. It would also be good if you started another thread because there are people interested in this but they would never guess it being what is wrong with this. Do you see my point?

sorry,
h3ckf1r3