Question

I think I know C++ reasonably well and I am thinking about implementing something a bit bigger than a “toy” program. I know the difference between stack- and heap-memory and the RAII-idiom.

Lets assume I have a simple class point:

class point {
public:
    int x;
    int y;
    point(int x, int y) : x(x), y(y) {}
};

I would allocate points always on the stack, since the objects are small. Since on 64-bit machines sizeof(point) == sizeof(void*), if a am not wrong, I would go even further and pass points by value by default.

Now lets assume a more complex class battlefield, that I want to use in the class game:

class battlefield {
public:
    battlefield(int w, int h, int start_x, int start_y, istream &in) {
        // Complex generation of a battlefield from a file/network stream/whatever.
    }
};

Since I really like RAII and the automatic cleanup when an object leaves the scope I am tempted to allocate the battlefield on the stack.

game::game(const settings &s) :
        battlefield(s.read("w"), s.read("h"), gen_random_int(), gen_random_int(), gen_istream(s.read("level_number"))) {
    // ...
}

But I have several problems now:

• Since this class has not got a zero-args-constructor I have to initialize it in the initialisation list of the class I use battlefield in. This is cumbersome since I need a istream from somewhere. This leads to the next problem.

• The complex constructors “snowball” at some point. When I use battlefield in the game class and initialize it in the initialisation list the constructor of game, the constructor of game will become fairly complex too and the initialisation of game itself might become cumbersome too. (When I decide to take the istream as argument of the game constructor)

• I need auxiliary functions to fill in complex parameters.

I see two solutions to this problem:

• Either I create a simple constructor for battlefield that does not initialize the object. But this approach has the problem that I have a half-initialized object, aka an object that violates the RAII-idiom. Strange things might happen when calling methods on such an object.

  game::game(const settings &s) {
      random_gen r;
      int x = r.random_int();
      int y = r.random_int();
      ifstream in(s.read("level_number"));
      in.open();
      this->battlefield.init(s.read("w"), s.read("h"), x, y, in);
      // ...
  } 
  

• Or I allocate battlefield on the heap in the game constructor. But I have to beware of exceptions in the constructor and I have to take care that the destructor deletes the battlefield.

  game::game(const settings &s) {
      random_gen r;
      int x = r.random_int();
      int y = r.random_int();
      ifstream in(s.read("level_number"));
      in.open();
      this->battlefield = new battlefield(s.read("w"), s.read("h"), x, y, in);
      // ...
  } 
  

I hope you can see the problem I am thinking of. Some questions that arise for me are:

• Is there a design pattern for this situations I do not know?

• What is the best practise in bigger C++ projects? Which objects are allocated on the heap, which ones are allocated on the stack? Why?

• What is the general advice regarding the complexity of constructors? Is reading from a file too much for a constructor? (Since this problem mostly arises from the complex constructor.)

Answer 1

You could let your battlefield be constructed from settings:

explicit battlefield(const settings& s);

or alternatively, why not create a factory function for your battlefield?

E.g.

battlefield CreateBattlefield(const settings& s)
{
    int w = s.read("w");
    int h = s.read("w");
    std::istream& in = s.genistream();
    return battlefield(w, h, gen_random_int(), gen_random_int(), in);
}

game::game(const settings &s) :
    battlefield(CreateBattlefield(s)) {
    // ...
}