Multiple C++ files and variable scope [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting ans开发者_开发技巧wers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 6 years ago.

Improve this question

I have a program, it starts in a winmain which calls run_game in its loop.

Because I treat run_game like a main function I am having to define many global variables.

The win main is in one file and everything is in another .cpp file. It started as a tutorial from a book and I have kept adding to it for a while now. Because my code is getting so big I want to break it into several .cpp files but I have a few question about doing so.

I see a lot of people having one giant source file. I am self taught so not sure if this has a benefit or is just style.
People say globals should be avoided so how can I make variables I declare in functions available in other files.
Is my program in a function approach a bad way of doing it as my plan was to break my run_game function into several smaller functions, each function would than be a state of the game.

I know people may complain this is vague so if you vote to close please comment on how I could make the question clearer.

Edit: I do know how to use classes and have 4 classes and 3 structs in the header file for this program, but an instance of a class acts the same as a variable so does not solve the problem of scope.

I see a lot of people having one giant source file. I am self taught so not sure if this has a benefit or is just style.

Its usually better to have smaller well defined files instead of one giant source file. Each file would either have a single C++ class definition or a set of interrelated functions. A rough guideline is no more than a few hundred lines of C++ code, but its subjective and difficult to quantify. You may often need much less or a lot more.

People say globals should be avoided so how can I make variables I declare in functions available in other files.

You need to pass those variables as parameters to those functions. For example if run_game calls foo, and foo needs to know the current score, pass the score in as an argument, like so:

void run_game()
{
     int score = 0;

     ...
     foo(score);
}


void foo(int score)
{ 
    // do some stuff
}

This is known as "pass by value", foo is getting its own copy of score. So if foo updates score, the caller's copy won't get updated. You can let foo update score by using pass by reference as so:

void foo(int& score) // notice the ampersand
{
    // add 100 pts
    score += 100;
}

Now you may ask, well I've got 50 variables, how could I possibly pass all 50 into foo? This is where the hard work of software engineering comes into play. You have a couple of options. In any option, you want to think about how pieces of variables group together. You might find you're always passing the same 5 variables into the function foo. Maybe its some representation of the players accomplishments so far in the game. The simplest way to gorup these together is with a struct:

struct PlayerAccomplishments
{
    int playersScore;
    int numGoblinsSlayed;
    int numTrollsSlaved;
};

Now you can declare variables of this type, set the specific fields, and pass them around:

void run_game()
{
     PlayerAccomplishments accomplishments;

     ...
     foo(accomplishments);
}


void foo(PlayerAccomplishments& playerAccomps)
{ 
    // do some stuff
    playerAccomps.numTrollsSlayed++;
    playerAccomps.playerScore += 100;
}

The next step in abstraction would be wrapping a set of variables and common pieces of functionality into a class. This lets us easily share common functionality and enforce a safe, well way for manipulating these objects--as defined by that object's member functions. So for example if we had a player class.

class Player
{
private:
    int score;
    int numTrollsSlayed;
public:
    // safely update the player's score after slaying a troll
    void SlayTroll(Troll& aTroll);
};

// in the cpp
Player::SlayTroll(Troll& aTroll)
{
    score += 100;
    numTrollsSlayed += 1;
}

Then the code above becomes:

void run_game()
{
     Player aPlayer;

     ...
     foo(aPlayer);
}


void foo(Player& aPlayer)
{ 
    Troll someTroll;
    aPlayer.SlayTroll(someTroll); // updates aPlayer's score
}

I hope you can see that there's a lot of ways to think about these problems, and its not easy to figure out how to seperate things out. This answer barely scratches the surface. I recommend a good course or book in software engineering. This stuff is hard. Really smart people with decades of experience struggle with the best way to organize and write software. But its great to think about this stuff. Its good to work hard to find ways to improve your code so you'll be able to make sense of what you're trying to do today, tomorrow, and six months from now.

Respective answers:

Having giant source file has more drawbacks. Even making a small change in one of it's module lets you compile the full file (increase in compile time). Code becomes less maintainable. If you divide in multiple files,you can name those files according to different modules and get into it when some issue comes.
If you use C++, then simply declare those globals as static variable in a class (or namespace). Put that class in a header file and define those statics in a .cpp file
This question is subjective. You should always decide based on your requirement and what you find easier in present and future.

Game design and architecture is a complex topic and it is not clear from your question what exactly you are trying to accomplish. First, everything in a HUGE file does not give any benefit in terms of performance. It is not bad style as long as it is readable, but you will find that most of the time, at some point, projects grow so that you will want to split logically different things in different files.

Second, everything in a HUGE function is definitively bad style in C++. Functions and object-oriented programming (classes, methods) help people write and maintain code and it is imperative that you use these features even in the most trivial examples. They pay for the extra overhead and are always worth it.

Third and last, globals are controversial. Some people say they are always bad. I'd say it depends. You do not provide enough information in your question so that I can decide. However, if you are in doubt, double check if you could not use classes to organize things in a better way. An object can have state (data fields) which behave as if they were global for the methods in the class, but are hidden from the rest of the world. Read a book or search the internet for Object Oriented Programming.

Having only one file means you will recompile all your code every time you change something. Depending on your machine and the amount of code you have, it can be quite long. Of course you will encounter other downsides as your code base grows (collaboration, organisation of your code...)
and 3. From what you are saying, it seems you are working more like in a C-way than C++. Do you know what are classes, objects... ? It could help you breaking you program in smaller pieces, but if you used a functionnal approach, it may means a lot of work.

Edit: I do know how to use classes and have 4 classes and 3 structs in the header file for this program, but an instance of a class acts the same as a variable so does not solve the problem of scope.

That's not really true. Most posts here are pointing in the right direction. But I miss the information that it's a wise decision to have a class to handle the game state.
This class would instantiate the class "game" and run the main-loop. This class also handles these variables like game-time and score. In this approach you don't need global variables and the variables are within a class with a limited scope. If you are familiar with classes you should already think of ways how to pass these values between classes.
There are quite many resources about game architecture out there. A common approach is to have a game loop and two methods: move and render, one to handle the gameplay, like moving characters, monsters and world items, the other to render the game on the screen.