title: Writing/Designing a simple object manager (game context)
body: <p>There are multiple parts to this question, which is why the title is a bit vague. Some of the syntax is left off for sake of brevity. Most of this is just using some convenient examples for learning, what I mean by that may become apparent.</p>
  
  <p>I started off with something like this:</p>
  
  <pre><code>class EntityManager {
      // ...
    private:
      map&lt;string, Entity&gt; _entities;
  }
  // definition of some add method
  void EntityManager::add ( ... ) {
      _entities.emplace( std::piecewise_construct,
                         std::forward_as_tuple( ... ),
                         /* and so on */ );
  }
  </code></pre>
  
  <p>where the map would hold the entire game entity (which is fixed in size), and adding would involve <code>emplace</code>.</p>
  
  <p><strong>Question 1.</strong> Is this smart? Or is it inefficient in some way vs holding onto a pointer as the value in the map?</p>
  
  <p><strong>Question 2.</strong> Say that <code>Entity</code> (or some sub-class) became dynamic in size in some way. Is there anything to stop this approach from handling it?</p>
  
  <p>I'm assuming that <code>emplace</code> will allocate the object on the heap and maintain an internal pointer. I can write a <code>get</code> method like this to treat it like a reference.</p>
  
  <pre><code>Entity&amp; EntityManager::get(std::string entityId)
  {
      auto results = _gameEntities.find(entityId);
      if (results == _gameEntities.end()) {
          return Entity(); //this is bad, right?
      }
  
      return results-&gt;second;
  }
  </code></pre>
  
  <p><strong>Question 3.</strong> Of course, returning a reference to a local stack-allocated object is bad. Since I can't return NULL, is the only solution here to use exceptions?</p>
  
  <p>The only other "problem" with this <code>map&lt;string, Entity&gt;</code> approach I've noticed, is that I can only make modifications to a game object that I'm creating by first <code>add</code>ing it, then requesting a reference to it with <code>get</code>, and then making my modifications. That's a little ugly, and also adds some overhead to object creation.</p>
  
  <p>So now, I switch to a pointer design:</p>
  
  <pre><code>class EntityManager {
      // ...
    private:
      map&lt;string, unique_ptr&lt;Entity&gt;&gt; _entities;
  }
  </code></pre>
  
  <p>That gives me two options for how to handle adding items</p>
  
  <pre><code>// OPTION 1: create a unique_ptr elsewhere, then move it.
  
  void EntityManager::add( string id, unique_ptr&lt;Entity&gt; ptr) {
      _entities.insert( std::make_pair(id, std::move(ptr)) );
  }
  
  // object creation
  unique_ptr&lt;Entity&gt; uPtr(new Entity());
  _entityManager.add("entity1", std::move(uPtr));
  
  // OR
  
  // OPTION 2: Create a naked pointer elsewhere, create a unique_ptr on insert
  
  void EntityManager::add( string id, Entity* ptr ) {
      _entities.insert(make_pair(id, unique_ptr&lt;Entity&gt;(ptr)));
  }
  
  // object creation
  Entity* e = new Entity();
  _entityManager.add("entity1", e);
  </code></pre>
  
  <p><strong>Question 4.</strong> Is there effectively any difference between these approaches? Or a preferred way?</p>
  
  <p>I think that's all the specific items I have, thanks for reading. Actually...</p>
  
  <p><strong>Question 5.</strong> Is there anything jumping out as wrong/notable that I've missed?</p>