   Reference initalisation in base class
  Hey,Its been a while since I did any C++ so go easy on me :)I'm implementing the following classes, they are entities which need to access an object of class 'gameworld'.How can I avoid passing the gameworld reference in every derived constructor?  I could use a pointer obviously, and just a set function in the base class, but is there a better way to initalise the gameworld refernce?class sgentity_base{public:sgentity_base(gameworld &parentworld);virtual ~sgentity_base(); ...protected:gameworld&world;}//constructor implementationsgentity_base::sgentity_base(gameworld &parentworld) : world(parentworld){}class sgentity_player : public sgentity_base{public:sgentity_player(gameworld &parentworld);virtual ~sgentity_player(); ...};//constructor implementationsgentity_player::sgentity_player(gameworld &parentworld) : sgentity_base(parentworld){}
  The first question to answer is whether your entities really need unfettered access to the world in which they live.The approach I use most commonly is that there exists some class (I'll call it the "world" class for lack of a better term) which owns the game-state, is responsible for enforcing the "rules" and "process" of the game and does so by delegating to entities and other classes as appropriate. These entities and classes can access the game-state either by being passed portions of the state through parameters or by the world class responding to return values. This allows you to pass as much or as little state as is required to do the job. For example, Entity.CheckCollide needs access to terrain, enemy and player positions, while Entity.GoToSleep probably doesn't need access to any state at all.Granting all Entity functions access to all of gameworld violates encapsulation (rapes it, really), increases coupling, and encourages sloppy coding by discouraging you from thinking about what a function actually needs. If, in the unlikeliest of events, you find yourself with a true need to access all of gameworld from another class, then you still have that freedom, just don't let it become the first tool you reach for.Another way to think about why this is bad is this: I presume that your gameworld class probably has some method(s) to Initialize, Reset or Clean Up the state. Do you really want any Entity to have the power to do any of these things? I think not.One of the key tasks of software engineering is interface design, which defines the relationships that can exist between classes. Interface design is as much about limiting access as it is about providing it. The ideal interface makes common thing easy, unlikely things hard and undesirable or dangerous things impossible.   ;  @Ravyne:Maybe we might be talking about two different things, but in my own games the "World" is the interface through which an Entity can request new entities be created, and request a list of close entities given a predicate function. These are things that are reasonable for any given Entity to do when updating() itself, IMO. The create and destroy methods are the constructor and destructor respectively, which while a Entity could technically call these on a reference parameter - you have bigger problems if this is the kind of thing you feel you need to guard against [grin]   ;  1) What's a "sgentity"? I don't know how to pronounce that, even. Did you possibly mean "sg::entity"?2) For that matter, isn't "entity_base" kind of redundant? I understand that "entity" is a name you're giving to your base class. A player is a kind of entity. Similarly, "entity_player" sounds awkward; you wouldn't say "job_fireman", would you?3) If the destructor doesn't do anything, there's no need to re-declare it in the derived class. All you need is a defined, empty, virtual destructor for the base, to make sure that destructors are dispatched polymorphically. And in modern C++, it's unusual to have to do anything explicitly in the destructor.4) It's common, and not particularly problematic, to implement empty functions (especially constructors and destructors) within the class body. These things are unlikely to change. Really.namespace sg {class entity {public:entity(gameworld& parentworld): world(parentworld) {}virtual ~entity() {} //...protected:gameworld& world;};class player: public entity {public:player(gameworld& parentworld): base(parentworld) {} //...};}5) I think keeping a reference to the world like this is fine. The entities only get access to the public interface of World, anyway, and I think they're entitled to know which World they live in. (But note that as a rule of thumb, elements of a container should not know which element they are of the container, if the container is ordered, or what key identifies them, if the container is keyed. Either of these duplicates information.) This is a fine example of "dependency injection".6) To answer the actual question: there isn't really any getting around it. If you had a set() function that was called from the base class constructor, you would still have to communicate to the base class constructor what parameter to set() with; and if you designed with the expectation of calling it from outside, then you are making all the calling code do extra, unintuitive work to save yourself a minor implementation hassle.But note that using references as data members is tricky, in general. In particular, it tends to inhibit copying instances of the class. You should think about using a pointer, or some kind of smart pointer, instead. (In this case, the class never "owns" the pointed-at World, so a raw pointer with an understanding of "weak pointer" semantics should be fine.)Quote:Another way to think about why this is bad is this: I presume that your gameworld class probably has some method(s) to Initialize, Reset or Clean Up the state. Do you really want any Entity to have the power to do any of these things? I think not.Maybe your Worlds do, but I prefer to Initialize() by calling a constructor, Reset() by overwriting with (assigning from) a default-constructed temporary, and CleanUp() by letting it fall out of scope (invoking the destructor).But in the case where the project is big enough to justify a deliberate limitation on Entity's interface to World (why not just not use the parts you shouldn't? You know, those crazy Pythonistas make do without 'private', even!), there are techniques for that:class EntityWorldInterface {  World* world; // weak pointer  public:  EntityWorldInterface(const World& w): world(&w) {}  void wibble() { w->wibble(); }  int wobble() { return w->wobble(); }};class Entity {  EntityWorldInterface ewi;  public:  Entity(const EntityWorldInterface& ewi): ewi(ewi) {}};// As it stands, the EWI constructor is not 'explicit', so we can pass a World// directly to the Entity constructor and it will get "wrapped" automatically.;  Thanks for the advice, some good things to think about.  I'm continuing with the world reference for now.  I suppose I could use a const reference which would preserve a bit more encapsulation (Init functions would be non const).Good point about the namespace, I often tend to forget them, hence the prefix.   