Jump to content
  • Advertisement
Sign in to follow this  
g0nzo

extern problem

This topic is 4925 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi! This was probably asked many times before but i really can't find a solution. I have few classes declared in separate header files like this:
#ifndef _INPUT_H_
#define _INPUT_H_

class CInput  
{
    blabla;
};

extern CInput *input;

#endif

In Windows.cpp file where i got WinMain function i include Input.h and do CInput *input = new CInput(); But when linking, wherever i'm using input pointer (even in Windows.cpp) i get error: [Linker error] undefined reference to `input'(i'm using Dev-cpp). What's wrong?

Share this post


Link to post
Share on other sites
Advertisement
What does 'nm Windows.o' output (at least for the input symbol) ?
What does nm output for the other object files ?

Share this post


Link to post
Share on other sites
The actual instance of CInput needs to go inside the "input.cpp" file

General rules: always declare things in header files (i.e. use extern) never
place instances in header files. The instances go in the corresponding source file (*.cpp)

Basically, in your case its poor form to declare
 extern CInput* input

within "input.h" and then make an instance of it within "windows.cpp".

Also, inside windows.cpp you have re-declared a private "version" of CInput

i.e. Change

CInput* input = new CInput(...)

to

input = new CInput(...)

--------------------------------------------------------------------

"proper" way of doing it:

//--------------------
// input.h:

class CInput{
....
};

extern CInput input; // no pointer


//---------------------
// input.cpp:

#include "input.h"

CInput input;




Share this post


Link to post
Share on other sites
Quote:
Original post by TheFatGecko
Forgot to say, have a google about good c/c++ style and header files and singletons


It's not poor style, and putting the instance at static global scope could be impossible sure it's not a good idea to litter globals like that but it could be a nice way to get things done and heck you can't say for sure that that object could be constructed like that and your new line is just wrong.

About the only thing you got right was how he should declare the variable being defined in a source file.

Share this post


Link to post
Share on other sites
DigitalDelusion

I don't get your critism. What's not poor style? I clearly stated that
placing a declaration in one header file and the instance in another is poor form. End of story. Whether or not the instance is a static or needs to be initialised by some class within the "input.cpp" file is up to guy writing.

Share this post


Link to post
Share on other sites
Look over what you posted.
You don't have any better style you made the (probably false) assumption that CInput could be constructed without preconditions and you botched the code.

Yes his design should probably be reworked to better hide the details either via a singleton a procedural interface or by simply passing around the CInput pointer without making it global.

So you didn't solve his problem and posted erranous code claiming it to be better, that's hardly helpful in my eyes.

Share this post


Link to post
Share on other sites
Thanks
I don't want singletons, i'm doing it just for myself so i will know which class should have only one instance. Maybe if everything will work ok i'll implement them.

I was trying to obtain a global pointer to a class, not global instance of a class (but maybe i'll change my mind). If i understood right i should put "input = new CInput();" into Input.cpp, but then how will i know when it's created i.e. before or after my logging class which will also have global pointer and will be created in the same way?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!