C++ std::map holding ANY type of value

This is plain in C++ 17. Use std::map + std::any + std::any_cast:

#include <map>
#include <string>
#include <any>
        
int main()
{
    std::map<std::string, std::any> notebook;

    std::string name{ "Pluto" };
    int year = 2015;

    notebook["PetName"] = name;
    notebook["Born"] = year;

    std::string name2 = std::any_cast<std::string>(notebook["PetName"]); // = "Pluto"
    int year2 = std::any_cast<int>(notebook["Born"]); // = 2015
}

Blindy's answer is very good (+1), but just to complete the answer: there is another way to do it with no library, by using dynamic inheritance:

class MyFieldInterface
{
    int m_Size; // of course use appropriate access level in the real code...
    ~MyFieldInterface() = default;
}

template <typename T>
class MyField : public MyFieldInterface {
    T m_Value; 
}


struct MyClass {
    std::map<string, MyFieldInterface* > fields;  
}

Pros:

• it's familiar to any C++ coder
• it don't force you to use Boost (in some contexts you are not allowed to);

Cons:

• you have to allocate the objects on the heap/free store and use reference semantic instead of value semantic to manipulate them;
• public inheritance exposed that way might lead to over-use of dynamic inheritance and a lot of long-term issues related to your types really being too inter-dependent;
• a vector of pointers is problematic if it have to own the objects, as you have to manage destruction;

So use boost::any or boost::variant as default if you can, and consider this option only otherwise.

To fix that last cons point you could use smart pointers:

struct MyClass {
    std::map<string, std::unique_ptr<MyFieldInterface> > fields;  // or shared_ptr<> if you are sharing ownership
}

However there is still a potentially more problematic point:

It forces you to create the objects using new/delete (or make_unique/shared). This mean that the actual objects are created in the free store (the heap) at any location provided by the allocator (mostly the default one). Therefore, going though the list of objects very often is not as fast as it could be because of cache misses.

If you are concerned with performance of looping through this list very often as fast as possible (ignore the following if not), then you'd better use either boost::variant (if you already know all the concrete types you will use) OR use some kind of type-erased polymorphic container.

The idea is that the container would manage arrays of objects of the same type, but that still expose the same interface. That interface can be either a concept (using duck-typing techniques) or a dynamic interface (a base class like in my first example). The advantage is that the container will keep same-type objects in separate vectors, so going through them is fast. Only going from one type to another is not.

Here is an example (the images are from there): http://bannalia.blogspot.fr/2014/05/fast-polymorphic-collections.html

However, this technique loose it's interest if you need to keep the order in which the objects are inserted.

In any way, there are several solutions possible, which depends a lot on your needs. If you have not enough experience with your case, I suggest using either the simple solution I first explained in my example or boost::any/variant.

---

As a complement to this answer, I want to point very good blog articles which summarize all C++ type-erasure techniques you could use, with comments and pros/cons:

• http://talesofcpp.fusionfenix.com/post-16/episode-nine-erasing-the-concrete
• http://akrzemi1.wordpress.com/2013/11/18/type-erasure-part-i/
• http://akrzemi1.wordpress.com/2013/12/06/type-erasure-part-ii/
• http://akrzemi1.wordpress.com/2013/12/11/type-erasure-part-iii/
• http://akrzemi1.wordpress.com/2014/01/13/type-erasure-part-iv/

Use either boost::variant (if you know the types you can store, it provides compile time support) or boost::any (for really any type -- but that's kind of unlikely to be the case).

http://www.boost.org/doc/libs/1_55_0/doc/html/variant/misc.html#variant.versus-any

Edit: I cannot emphasize enough that although rolling your own solution might seem cool, using a complete, proper implementation will save you a lot of headache in the long run. boost::any implements RHS copy constructors (C++11), both safe (typeid()) and unsafe (dumb casts) value retrievals, with const corectness, RHS operands and both pointer and value types.

That's true in general, but even more so for low level, base types you build your entire application on.