Question

I’m trying to create a generic storage class in C++. If you look at the code bellow, I’m want to store maps of string / AnyType and access them.

  class StoresTestC
  {
  public:
    template < class SettingsType >
    std::map< std::string, SettingsType >* getStore(std::string const&);
  private:
    std::map< std::string, void* > stores_;
  };

  template < class SettingsType >
  std::map< std::string, SettingsType >* StoresTestC::getStore(std::string const& name)
  {
    if (stores_.count(name) > 0)
    {
      void* temp = this->stores_[name];
      return (std::map< std::string, SettingsType >*)(temp);
    }
    else
    {
      std::map< std::string, SettingsType > * result = new std::map< std::string, SettingsType > ();
      this->stores_[name] = result;
      return result;
    }
  }

I see two obvious dangers in doing so:

1. If I call it with a wrong SettingsType / name I will call a wrong cast which as far as I know (I may be wrong) will lead to an undefined behaviour.

2. It will create a memory leak, but I have a solution for that (which was two long too be disclosed here).

Is there anything else that can go wrong and you can you forsee ?

Answer 1

First take a step back and make sure you really want to do this. Then look at your design one more time.

OK, you still need this capability?

Use std::map<std::string, boost::any> where the boost::any is always a map type. Then when you use any_cast or whatever mechanism to get the item back out, you’re guaranteed that it’s the right type or it throws so you never risk undefined behavior. Additionally since the any is by value you don’t have a possible memory leak floating around either.

I should also note that in your original solution if you use a shared_ptr<void*> it would remember how to delete the original type stored in that shared_ptr thus removing the memory leak you mentioned.

EDIT: I can’t see any other obvious technical problems with something like this. However note that having such a map is possible/likely to cause cognitive (“grokking”) problems for future maintainers, and does increase the complexity of the code somewhat.