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
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
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
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:
For example, if you wanted a simple subroutine that outputted the square of a number, you would:Code:return-type function-name(parameter-list) { statements }
The data type void means that it returns no value, hence a subroutine. If you want to return values, it would be a function.Code:void square(int value) { std::cout << (value * value) << std::endl; }
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.
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.
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.
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:
Just keeping everyone standard. To replace using namespace std; you do this: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; }
- SirCrono6Code: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
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
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:
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.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
DeadPoet
Last edited by deadpoet; 02-20-2004 at 08:37 PM.
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...
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.
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.
I did not see that I have exited on 1, been dealing with error crap all day and I think I was on autopilot.Code:#define EXIT_FAILURE 1 #define EXIT_SUCCESS 0
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.
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.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.
Last edited by Omnius; 02-21-2004 at 03:57 AM.
Omnius,
Where is this documented. I would like to read more on the matter. This infact would be a solid and compelling reason to change.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.
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.
The behaviour of exit() is documented in the C++ standard. Any good beginners book should cover it.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.
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. 676Now 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: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 let us examine yet another source for our knowledge quest.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 for some partial credit to your argument.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
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 eitherCode:#include <stdio.h> main(){ printf( "hello, world\n" ); }
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, 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.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
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.
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.Originally posted by deadpoet
Your thoughs, comments, and ideas are always welcome and I look forward to additional debate on the matter.
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.