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

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:

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.

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

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:

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. :D 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.

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

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.

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

Quote:

---

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.

Omnius,

Quote:

---

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

Quote:

---

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.

Well, let me quote a few sources:

Quote:

---

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

---

Quote:

---

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:

Quote:

---

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.

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

Thats right, local objects are not destroyed. Globla objects may be.

Yes, I agree that local object are not destroyed as in the following case:

Example 1: Local FOO Using Return

Code:

---

#include <stdlib.h>

class foo {
  public:
  int x;

  foo( int i ) {
    x = i;
  }
  void print( void ) {
    printf( "Hello, foo x val=%d\n", x );
  }

  ~foo(){
    printf( "foo destructor\n" );
  }

};

int main ( void ) {
  foo FOO( 1);
  FOO.print();
  return ( EXIT_SUCCESS );
}


###############OUTPUT###############
# ./foo
Hello, foo x val=0
foo destructor

---

Example 2: Local FOO Using Exit

Code:

---

#include <stdlib.h>

class foo {
  public:
  int x;

  foo( int i ) {
    x = i;
  }
  void print( void ) {
    printf( "Hello, foo x val=%d\n", x );
  }

  ~foo(){
    printf( "foo destructor\n" );
  }

};

int main ( void ) {
  foo FOO( 1 );
  FOO.print();
  exit ( EXIT_SUCCESS );
}


###############OUTPUT###############
# ./foo
Hello, foo x val=0

---

Now let me clean this up a little to simulate a more realistic approach:

Example 3: Global FOO Using Return

Code:

---

//FileName: foo.cc
#include "foo2.h"

foo FOO(1);  // FOO defined at a global level.

int main ( void ) {
  FOO.print();
  return ( EXIT_SUCCESS );
}

// File Name: foo2.h
#ifndef _FOO2_H_
#define _FOO2_H_

#include <stdlib.h>

class foo {
  public:
    int x;
    foo( int i );
    ~foo();
    void print( void );
};
#endif

// File Name: foo2.cc
#include "foo2.h"

foo::foo( int i ) {
    x = i;
}
void foo::print( void ) {
    printf( "Hello, foo x val=%d\n", x );
}

foo::~foo(){
    printf( "foo destructor\n" );
}
###############OUTPUT###############
# ./foo
Hello, foo x val=1
foo destructor

---

Example 4: Global FOO Using Exit

Code:

---

//FileName: foo.cc
#include "foo2.h"

foo FOO(1);  // FOO defined at a global level.

int main ( void ) {
  FOO.print();
  exit ( EXIT_SUCCESS );
}

// File Name: foo2.h
#ifndef _FOO2_H_
#define _FOO2_H_

#include <stdlib.h>

class foo {
  public:
    int x;
    foo( int i );
    ~foo();
    void print( void );
};
#endif

// File Name: foo2.cc
#include "foo2.h"

foo::foo( int i ) {
    x = i;
}
void foo::print( void ) {
    printf( "Hello, foo x val=%d\n", x );
}

foo::~foo(){
    printf( "foo destructor\n" );
}
###############OUTPUT###############
# ./foo
Hello, foo x val=1
foo destructor

---

And if FOO was created using foo FOO = new foo( 1 ) then niether return nor exit will call the destructor. One would need to do something like if ( FOO ) { delete FOO; } .

So, with this being said, I understand your point and see the validity in your statements. Everything must be put into the context of what you are accomplishing. If the objects are only local object then yes return should be invoked however, if the objects are global or created with new then it really does not matter and should be left to the coders choice. I say this because if the object is global then both return and exit invoke the destructor. If the object is created using new then niether return nor exit will invoke the destructor; the memory must be freed using delete.

This has been a great topic and has led me to look into a few of the elements of C++ that I have taken for granted. I can see the merit in the argument for the use of return.

DeadPoet.

There shouldn't be any global objects. But there may be singletons that use static class members, which results in the same. Anyway, these get cleaned up regardless of the exit type.

However, I disagree on the point of dynamic memory, because I rarely use raw pointers. My code would be:

Code:

---

int main()
{
  boost::scoped_ptr<FOO> fooptr(new FOO);
  (exit type)(1);
}

---

return calls the smart pointer destructor and thus deletes and destructs the dynamic object, exit doesn't.

wow, this thread has gotten pretty big! can u give me a nice, easy, correctly formated example of a subroutine? that other guy had put all his commands on the same line, which for me, is hard to read. also, please comment it alot. thx so much