1

I have a project, for example game application. I have a lot of classes in there. So, where should I store initial variable declaration/definition of game parameters?

For example, I have a 'plane' which has initial parameters speed,height, e.t.c.
After game has started this parameters somehow depends on game process, and changing in time parameters I should also store in some file.
The same situation with another classes, for example initial score/fuel/health... Also there is some constexpr parameters like quantity of added score per seconds.

So, where should I store all this parameters? I have some idea about that:

  1. If I store it in Parameters.h file like:
namespace WINDOW_PARAM {
    static const unsigned int WIDTH = 1000;
    static const unsigned int HEIGHT = 1000;
}
namespace PLANE_PARAM {
    static const char *TEXTURE_PATH = "../example.png";
}

then I will get my compilation time too big. That's because some classes contains this file, and If I test best-parameters I will modify it and it's will be too long.

  1. Another way - create config file and somehow parse from it. That's will decrease compile time and easy to modify, but it seems hard in architecture cases, because there are will be a lot of dependencies.
  2. Just declare each constant in each class. - too long to modify, because I should open Plane.h - modify, then Window.h .. e.t.c

How big project game solve this problem (it means that they are testing/developed - should build less and keep simple architecture)? Is it a good practice to use extern like an answer below?

Mike
  • 342
  • 4
  • 13
  • If they're parameters that are often changed then #2 is the best way to do it. – Hatted Rooster Jan 16 '21 at 14:43
  • *"how I should deal with it"* -- this is rather subjective. See the [help/dont-ask] for advice on how to make this question more constructive (e.g. more focus on pros and cons). – JaMiT Jan 16 '21 at 14:46
  • @JaMiT Is it OK now? – Mike Jan 16 '21 at 15:21
  • @HattedRooster It is a good practice to use `extern` like in answer? – Mike Jan 16 '21 at 15:21
  • @Mike Asking about what is done in existing projects is better than asking what should be done in your project. So, yes, there is improvement. However, your project is not those projects. You would benefit more from knowing *why* those choices were made so you can evaluate if those reasons are applicable to your project. – JaMiT Jan 16 '21 at 15:27
  • Referencing an answer in the question it answers is fishy. I would drop *"Is it a good practice to use `extern` like an answer below?"* and expect that answers demonstrating bad practices will get downvoted. – JaMiT Jan 16 '21 at 15:30

1 Answers1

2

You can declare the variables as extern in your header, and have a .cpp with the actual values.

Parameters.h

namespace WINDOW_PARAM {
    extern const unsigned int WIDTH;
    extern const unsigned int HEIGHT;
}
namespace PLANE_PARAM {
    extern const char *TEXTURE_PATH;
}

Parameters.cpp

namespace WINDOW_PARAM {
    const unsigned int WIDTH = 1000;
    const unsigned int HEIGHT = 1000;
}
namespace PLANE_PARAM {
    const char *TEXTURE_PATH = "../example.png";
}

Now you can #include "Parameters.h" everywhere. Changing the values in Parameters.cpp will only recompile that file.

super
  • 12,335
  • 2
  • 19
  • 29
  • Is it really a good practice to use `extern`? Of course it in `namespace`, but I have some doubt. Also it's [not possible](https://stackoverflow.com/questions/30208685/how-to-declare-constexpr-extern) to use `constexpr` in this cases – Mike Jan 16 '21 at 15:08
  • In my experience, globals should be used sparingly in all cases. But for constants it can make sense sometimes. I don't think that `extern` in general is a bad idea, but it comes with pros and cons. The pro here is that you can change the values without recompiling TUs that rely on them. The con you already pointed out, which also means the value is not available for the compiler to make optimizations. I would say it depends on what's more important in your project. – super Jan 16 '21 at 15:55