Thread: Couple of Q's.....

  1. #1
    Registered User
    Join Date
    Jul 2003
    Posts
    97

    Couple of Q's.....

    does c++ have subroutines? if so, whats the basic coding for them? and how do i make very simle graphics in c++, such as sprites? thx

  2. #2
    Registered User deadpoet's Avatar
    Join Date
    Jan 2004
    Posts
    50

    Cool

    Yes, C/C++ allow you to create functions(subroutines) for example:

    Code:
    #include <stdlib.h>
    #inclide <iostream.h>
    
    void foo ( int );  // Function Prototype.
    
    int main ( void ) {
      int i = 13;
      foo( i );
      exit ( 1 );
    }
    
    void foo ( int x ) {
      int z = x;
      cout << "Inside Foo: z =  " << z << endl;
      return;
    }

    Note that your function prototype is usually placed inside an include file something like foo.h but can reside inside your source foo.cc.

    Peace Out,

    DeadPoet

  3. #3
    Registered User
    Join Date
    Jan 2003
    Posts
    648
    That one line above the main() in his code is called the prototype. Its written if you share the function amongst files and/if you use the function before you actually define code for it. If he would've put the code of foo() above the function, he wouldn't need a prototype because he used the function before he used it (sequentially going down the file).

    A function looks like this:
    Code:
    return-type function-name(parameter-list) {
       statements
    }
    For example, if you wanted a simple subroutine that outputted the square of a number, you would:
    Code:
    void square(int value) {
       std::cout << (value * value) << std::endl;
    }
    The data type void means that it returns no value, hence a subroutine. If you want to return values, it would be a function.

    Go get a C++ book if you're just learning. Its better.

    Graphics aren't standard in C++. I *recommend* you actually know C++ before you tackle graphics. You will need to find a third-party library or check your compiler documentation or use your platform's API.

  4. #4
    Registered User deadpoet's Avatar
    Join Date
    Jan 2004
    Posts
    50
    Speedy5 is correct. If your functions are declared above main then there is no need to define a prototype for that function. However, it is good practice to define a prototype for all your functions because it adds clairity to what is available and set one up for a little more portability when you plan to expand your code.

    But in a nut he is 100% correct and there is nothing more important than begining to under stand how C/C++ work. The languages are very similar but are also very different and to tackle graphic programming from the get-go will be difficult without a firm understanding of how C/C++ work.

    DeadPoet
    Last edited by deadpoet; 02-20-2004 at 05:40 PM.

  5. #5
    Hardware Engineer
    Join Date
    Sep 2001
    Posts
    1,398

    There is no "gosub" in C or C++.

    I'd say the main difference between functions and subroutines is variable scope.

    In BASIC, a subroutine has access (or at least can have access) to all of the variables in your main routine. A C++ function has only local variables. You don't pass variables into functions. You pass-in values. Also, a function can only return one value.

    If you want to affect more than one variable, you have to use pointers and/or references.

    You can use global variables, but it is generally bad practice. (Function-libraries actually use globals rather freely.)

    I seem to remember subroutines from Fortran too... but I'm not sure... too many years since I took a Fortran class! I also think that most assembly languages have subroutines... I think I first learned about stack operations when learning how subroutines are handled in assembly/machine code.

  6. #6
    Rabite SirCrono6's Avatar
    Join Date
    Nov 2003
    Location
    California, US
    Posts
    269
    I haven't programmed in other languages, so I'm guessing DougDbug is probably right. Also, for graphics you can use Win32 API. Oh yeah:

    Code:
    #include <iostream>
    #include <cstdlib> //Why did you include that deadpoet?
    
    using namespace std; //There are other ways of doing this
    
    int main( void )
    {
    
      return 0; //exit( 1 ); works, but most people use return 0;
    }
    Just keeping everyone standard. To replace using namespace std; you do this:

    Code:
    using std::cout; 
    using std::endl;
    using std::cin; // Some of the most used std things, but there are others
    
    //or this
    
    int X;
    std::cout << "Bla..." << std::endl;
    std::cin >> X; //as an example
    - SirCrono6

    P.S. Dropping the .h on iostream and adding using namespace std; were mainly the only need changes.
    From C to shining C++!

    Great graphics, sounds, algorithms, AI, pathfinding, visual effects, cutscenes, etc., etc. do NOT make a good game.
    - Bubba

    IDE and Compiler - Code::Blocks with MinGW
    Operating System - Windows XP Professional x64 Edition

  7. #7
    Registered User deadpoet's Avatar
    Join Date
    Jan 2004
    Posts
    50
    SirCrono6,

    I did not #include <cstdlib>, included <stdlib.h> as on hpux, which is what I develop on, it seems to be where exit is defined.

    If you read the manpage for the exit function you will see that returning a value, like return 1, from main has the same effect.

    #> man exit

    exit(2) exit(2)

    NAME
    exit, _exit - terminate process

    SYNOPSIS
    #include <stdlib.h>

    void exit(int status);

    #include <unistd.h>

    void _exit(int status);

    DESCRIPTION
    exit() terminates the calling process and passes status to the system for inspection, see wait(2). Returning from main in a C program has the same effect as exit(); the status value is the function value returned by main (this value is undefined if main does not take care to return a value or to call exit() explicitly).

    ... REST OF MAN REMOVED TO KEEP IT SHORT


    There are 1000 diferent was to accomplish anything in C/C++, if one prefers exit over return, the fact still remains that you gave an int back to the operating system. I feel that return should be reserved for functions, methods, and such. When you exit a program you should indicate as such thus, my use of exit. I am exiting the program.

    However, if there is a solid reason as to why I should return instead of exit when I am leaving a program then I am all ears.

    Finally, just dropping the .h on iostream is not an option on all operating system and all compilers. It depends on how the it is implemented in the includes directory and how you are using it. Are you providing backwards compatibility? But in this case it would have worked, even on hpux, because I do have the following files:
    Code:
    # find /usr -type f -name iostream* -print
    /usr/local/include/c++/3.3.1/backward/iostream.h
    /usr/local/include/c++/3.3.1/iostream
    and I will make a note of it because I think that most of the code that I have written lately I used iostream.h.


    DeadPoet
    Last edited by deadpoet; 02-20-2004 at 08:37 PM.

  8. #8
    Registered User
    Join Date
    Jan 2003
    Posts
    648
    In the real world, as long as it works and its ok with company policy, who cares! If it works, don't mess with it.

    But as rule of thumb: whenever you can, use the newer stuff.

    I could post that neat problem solving flowchart but lol...

  9. #9
    Registered User
    Join Date
    Jan 2003
    Posts
    648
    Btw, you should really return 0 to the OS as its defined to be the success value on most operating systems. If you really want to be correct, you would use EXIT_SUCESS in stdlib.h/cstdlib.

    And C++ has an exception where you don't even have to return a value from main() and still, of course, declare it as an int. It puts a return for you at the end of the function.

  10. #10
    Registered User deadpoet's Avatar
    Join Date
    Jan 2004
    Posts
    50
    Speedy & SirCrono6, you are correct EXIT_SUCCESS is probably the more correct manner to leave a program and I should not have left it on 1 because it would indicate a failure thus, I should have left 0.

    Code:
    #define EXIT_FAILURE 1
    #define EXIT_SUCCESS 0
    I did not see that I have exited on 1, been dealing with error crap all day and I think I was on autopilot.

    Finally, I agree that if it works leave it alone, if you have time try to make it better, and if you do not care then get a beer.

    DeadPoet
    Last edited by deadpoet; 02-20-2004 at 10:01 PM.

  11. #11
    Registered User
    Join Date
    Sep 2003
    Posts
    135
    Originally posted by deadpoet
    There are 1000 diferent was to accomplish anything in C/C++, if one prefers exit over return, the fact still remains that you gave an int back to the operating system. I feel that return should be reserved for functions, methods, and such. When you exit a program you should indicate as such thus, my use of exit. I am exiting the program.

    However, if there is a solid reason as to why I should return instead of exit when I am leaving a program then I am all ears.
    In C++ the use of exit() is considered poor practice. Terminating the program using exit() doesn't invoke destructors for local objects. Better is to terminate with return via main() or throw an exception, the latter providing an opportunity for dealing with the condition that caused it.
    Last edited by Omnius; 02-21-2004 at 03:57 AM.

  12. #12
    Registered User deadpoet's Avatar
    Join Date
    Jan 2004
    Posts
    50
    Omnius,

    In C++ the use of exit() is considered poor practice. Terminating the program using exit() doesn't invoke destructors for local objects. Better is to terminate with return via main() or throw an exception, the latter providing an opportunity for dealing with the condition that caused it.
    Where is this documented. I would like to read more on the matter. This infact would be a solid and compelling reason to change.

    Does this allpy to main() or a class from which you exit? I typically exit main and return or throw from a class.

    DeadPoet
    Last edited by deadpoet; 02-21-2004 at 08:34 AM.

  13. #13
    Registered User
    Join Date
    Sep 2003
    Posts
    135
    Originally posted by deadpoet
    Where is this documented. I would like to read more on the matter. This infact would be a solid and compelling reason to change.
    The behaviour of exit() is documented in the C++ standard. Any good beginners book should cover it.

  14. #14
    Registered User deadpoet's Avatar
    Join Date
    Jan 2004
    Posts
    50

    Cool

    Well, let me quote a few sources:

    Calling the exit() standars library function is a more satisfactory way of terminating your program than calling abort().
    Calling exit() ensures that destructors for global objects are called, and any open input/output streams are flushed if necessary, and closed. Any temporary files created using the standard library will be deleted.

    Ivor Horton
    Ivor Horton's Beginning C++ pp. 676
    return

    Exits a function, returning control to the caller of the function, along with the function return value(if any).

    Rob McGregor
    Practical C++ pp. 74
    Now one might argue that main is a function, and I agree that it is a function, thus we should use return but we must look at the context in which the statement is made. Rob McGregor is speaking about functions other than main and if we read on in his book this becomes clear because he states on page 184 the following:

    The exit() Function
    Because Standard C is part of Standard C++, all the tried and true functions C programmers know and love are available in C++. The exit() function is used to terminate the program with an exit code for the operating system.

    Rob McGregor
    Practical C++ pp.184
    Now let us examine yet another source for our knowledge quest.

    Historically the exit function has always performed a clean shutdown of the standard I/O library: the fclose function is called for all open streams. Recall from Section 5.5 that this causes all buffered output to be flushed (written to the file).
    Both the exit and _exit functions expect a single integer argument, which we call the exit status. Most unix shell provide a way to examine the exit status of a process. If (a) either of these functions is called without an exit status, (b) main does a return without a return value, or (c) main "falls off the end" (an implicit return), the exit status of the process is undefined. This means that the classic example
    Code:
    #include <stdio.h>
    main(){
        printf( "hello, world\n" );
    }
    is incomplete, since the main function falls off the end, returning to the C start-up routine, but without returning a value (the exit status). Adding either
    return(0)
    or
    exit(0)

    provides an exit status of 0 to the process that executed this program (often a shell). Also, the declaration of main should really be
    int main(void)

    W. Richard Stevens
    Advanced Programming in the UNIX Environment pp. 162-163
    Now for some partial credit to your argument.

    The declaration of main as a returning an integer and the use of exit (instead of return) produces needless warnings from some compilers and the Unix lint(1) program. The problem is that these compilers don't know that an exit from main is the same as a return. The warning message is something like "control reaches end of non void function." One way around these warnings (which may become annoying after a while) is to use return instead of exit from main. But doing this prevents us from using the Unix grep utility to locate all calls to exit from a program. Another solution is to declare main as returning void, instead of int, and continure calling exit. This gets rid of the compiler warnings but does not look right (especially in a programming text).

    W. Richard Stevens
    Advanced Programming in the UNIX Environment pp. 162-163
    Now, let us evaluate what is being stated and the ramifications of not using exit to leave main. I feel that it is important for other programs to know how your program terminates. If we look at the behavior of a process that terminates normally, either by calling the exit function directly, or by returning from main, all standard I/O streams with unwritten buffered data are flushed, and all open standard I/O streams are written. Granted that return, when from main, should be the same as exit but it is not always the case. If other tools cannot determine the termination status of your program then there is a flaw in the design. Each has its' merits but for the sake of the calling shell it seems to be better to terminate main using exit thus allowing the status to be known.


    Your thoughs, comments, and ideas are always welcome and I look forward to additional debate on the matter.


    DeadPoet
    Last edited by deadpoet; 02-21-2004 at 12:19 PM.

  15. #15
    Registered User
    Join Date
    Sep 2003
    Posts
    135
    Originally posted by deadpoet
    Your thoughs, comments, and ideas are always welcome and I look forward to additional debate on the matter.
    You've quoted many sources, but so far not the source that actually defines the language, the C++ standard. You even include C, which is a different language, with different behaviour.

    The effect of calling exit is well defined, and does not include invoking the destructor for local objects, whether from main or from another function. Calling return from main does.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Studying for Final, Couple Questions...
    By stewade in forum C Programming
    Replies: 4
    Last Post: 05-10-2004, 05:02 PM
  2. Pokemon talk and a couple useless stories
    By TechWins in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 02-01-2003, 03:49 PM
  3. Thought I'd registered last couple of months...
    By Grayson_Peddie in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 08-31-2002, 09:34 PM
  4. Couple Code Snippets
    By Unregistered in forum Game Programming
    Replies: 1
    Last Post: 01-22-2002, 02:23 AM
  5. Replies: 5
    Last Post: 11-13-2001, 04:38 PM