Call a functions from one cpp in another...

[Josh]

Can I call a function from one .cpp file from another .cpp file? I have a function I want to put in this other file but it want recongize it. I have used #include <File.h or file.cpp> thing and still not luck. I have also tried the :: method too...any ideas an this is possible right?

[Bob]

Oct 13, 2010 13:51:05 GMT -8 Josh said:

Can I call a function from one .cpp file from another .cpp file? I have a function I want to put in this other file but it want recongize it. I have used #include <File.h or file.cpp> thing and still not luck. I have also tried the :: method too...any ideas an this is possible right?

So long as the function's prototype has been defined prior to the call, yes. This is most commonly done in a header file. Make sure you aren't using angle brackets with the include directive of a local file. Angle brackets tell your compiler to go looking for the header file in its standard include directory. You use quotes around header files if the file is within your project. As an example:

fileone.cpp

#include "filetwo.h"

int main ()
{
  someFunction ();
  return 0;
}

filetwo.h

#pragma once
#ifndef _FILETWO_H_
#define _FILETWO_H_

void someFunction ();

#endif

filetwo.cpp

#include <iostream>

void someFunction ()
{
  std::cout << "Junk." << std::endl;
}

In that example though I could have foregone a header file entirely and just declared the prototype within fileone.cpp. But for organizational purposes, and because declarations (especially classes) can get up in size, we use header files with the same name as the source file it's defining.

[Josh]

Oct 13, 2010 16:25:21 GMT -8 Bob said:

Oct 13, 2010 13:51:05 GMT -8 Josh said:

Can I call a function from one .cpp file from another .cpp file? I have a function I want to put in this other file but it want recongize it. I have used #include <File.h or file.cpp> thing and still not luck. I have also tried the :: method too...any ideas an this is possible right?

So long as the function's prototype has been defined prior to the call, yes. This is most commonly done in a header file. Make sure you aren't using angle brackets with the include directive of a local file. Angle brackets tell your compiler to go looking for the header file in its standard include directory. You use quotes around header files if the file is within your project. As an example:

fileone.cpp

#include "filetwo.h"

int main ()
{
  someFunction ();
  return 0;
}

filetwo.h

#pragma once
#ifndef _FILETWO_H_
#define _FILETWO_H_

void someFunction ();

#endif

filetwo.cpp

#include <iostream>

void someFunction ()
{
  std::cout << "Junk." << std::endl;
}

In that example though I could have foregone a header file entirely and just declared the prototype within fileone.cpp. But for organizational purposes, and because declarations (especially classes) can get up in size, we use header files with the same name as the source file it's defining.

Thanks, thats what I am doing but for some reason I can't get it to work correctly...

[Jordan]

Post your code.

[Josh]

Oct 13, 2010 17:59:15 GMT -8 Jordan said:

Post your code.

You know how I am about posting my code lol Here is the important pieces I cut out a bunch of stuff but still not working right... I am trying to call playerone function from player.cpp in my game.cpp file...

Player.cpp

#include "Player.h"


Player::Player(void){
		
}

void Player::playerone(){

	con->printChar(1,1,'@');
	
}

Game.cpp

#include "Game.h"
#include "Player.h"

Game::Game(void) {

}

Game::~Game(void) {
	
}

void Game::run() 
{

	Player::playerone();

}            

[Bob]

We need to see Player.h. And what's the exact error you're receiving? Unresolved external, right?

[Josh]

Oct 13, 2010 18:25:14 GMT -8 Bob said:

We need to see Player.h. And what's the exact error you're receiving? Unresolved external, right?

No, I receive this error

error C2352: 'Player::playerone' : illegal call of non-static member function

[Jordan]

You need to either make the function static or create an instance of the object. The choice you makes depends on what you are doing with your code.

[Josh]

Oct 13, 2010 18:37:26 GMT -8 Jordan said:

You need to either make the function static or create an instance of the object. The choice you makes depends on what you are doing with your code.

Well basically this function is just going to add a char to the screen and I am going to move it around with the arrow keys...so how do I know which one I need, I'm not sure...

[Jordan]

Your design seems to be a little off. When I think of a "player", I think of an object which has to be instantiated. This means you wouldn't have a "playerone" static function because each player would have its own function "printChar()".

In your program above, I would create a "Player" object in your "Game" object.

class Game {
    private:
        Player player;
    public:
        Game();
        ~Game();
        void run();
}

void Game::run() {
        player.print();
}

Static functions are good to have when you want to be able to use the function without creating an instance of the object. They're good to have for generic functions which may not necessarily be needed by the object that is instantiated, but they make since to be associated with that class. For instance, if I have a "Font" class in a GUI application, it may make sense to create a static function called loadFont() which can be easily called by other classes without having to instantiate an object which they may not need.

[Josh]

Oct 13, 2010 18:53:20 GMT -8 Jordan said:

Your design seems to be a little off. When I think of a "player", I think of an object which has to be instantiated. This means you wouldn't have a "playerone" function because each player would have its own function, which in this case would just print something.

In your program above, I would create a "Player" object in your "Game" object.

class Game {
    private:
        Player player;
    public:
        Game();
        ~Game();
        void run();
}

void Game::run() {
        player.print();
}

Static functions are good to have when you want to be able to use the function without creating an instance of the object. They're good to have for generic functions which may not necessarily be needed by the object that is instantiated, but they make since to be associated with that class. For instance, if I have a "Font" class in a GUI application, it may make sense to create a static function called loadFont() which can be easily called by other classes without having to instantiate an object which they may not need.

Ok, thanks still not sure exactly what to do but hopefully I will figure it out...I have to have in in that .cpp file and I don't think I can do that...arggg lol

[Josh]

I have another questions...I think I am getting closer!!! Can I have a pointer that calls a function, and in that function there is a point that calls another function? My program keeps crashing on me so I am not sure if it is possible or not. Thanks

[Jordan]

You could, but that to me sounds like you have a bad design. Function pointers can be awkward to work with, and if you really need one I recommend using a functoid which is an object that wraps a function and overloads the parenthesis operator. Then you pass the object as a parameter and can use it like a normal function although it's really not.

I have made several games, though, and I haven't had to so something like that except for GUI callback functions. If you organize your classes correctly you won't have to do something like that and your code will be easier to use and build off of. If you post your code or PM me I can give you a few suggestions.

[Josh]

Oct 14, 2010 10:46:27 GMT -8 Jordan said:

You could, but that to me sounds like you have a bad design. Function pointers can be awkward to work with, and if you really need one I recommend using a functoid which is an object that wraps a function and overloads the parenthesis operator. Then you pass the object as a parameter and can use it like a normal function although it's really not.

I have made several games, though, and I haven't had to so something like that except for GUI callback functions. If you organize your classes correctly you won't have to do something like that and your code will be easier to use and build off of. If you post your code or PM me I can give you a few suggestions.

Ok, I'll send you a pm...give me about 5-10 mins to get it all together...Thanks.

EDIT: Ok, I sent it.