Thread: Why wont this code work

  1. #1
    Registered User
    Join Date
    Jan 2008
    Posts
    5

    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 {
    Last edited by Mach1723; 01-04-2008 at 04:12 PM. Reason: Adding one more detail

  2. #2
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    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;
    }

  3. #3
    Registered User
    Join Date
    Jan 2008
    Posts
    5
    Oh thank you

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Code:
        a_file.close();
    Not necessary. The destructor does that automatically.
    Code:
        return 0;
    Also not necessary. Implicit in C++.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Good practice though. Helps to understand what's going on.

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    return 0, however, I think should be explicit.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #8
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    > return 0, however, I think should be explicit.

    I think it's safer in C++ to use the implicit return, since at least 95&#37; 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).

  9. #9
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > I think it's safer in C++ to use the implicit return, since at least 95&#37; 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;'.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  10. #10
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    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.
    Last edited by robatino; 01-05-2008 at 02:02 AM.

  11. #11
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > 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".
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  12. #12
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Quote Originally Posted by robatino View Post
    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.
    Last edited by King Mir; 01-05-2008 at 03:52 AM.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  13. #13
    Registered User
    Join Date
    Dec 2007
    Posts
    37
    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

  14. #14
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by h3ckf1r3 View Post
    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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #15
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    > 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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 11-15-2007, 01:36 AM
  2. Very short code tt never work...please help
    By newbie1234 in forum C Programming
    Replies: 7
    Last Post: 05-23-2006, 11:46 PM
  3. Binary Search Trees Part III
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 10-02-2004, 03:00 PM
  4. cant get code to work
    By duffy in forum C Programming
    Replies: 13
    Last Post: 10-20-2002, 05:23 AM
  5. << !! Posting Code? Read this First !! >>
    By kermi3 in forum Linux Programming
    Replies: 0
    Last Post: 10-14-2002, 01:30 PM