store in std::map all kind of structs

This is a discussion on store in std::map all kind of structs within the C++ Programming forums, part of the General Programming Boards category; Hello all and sorry for my bad english
i have std::map that uses string as akey and i like it ...

store in std::map all kind of structs

Hello all and sorry for my bad english
i have std::map that uses string as akey and i like it to hold different kinds of
structs ( my structs define in the application )
but how can i tell the map to hold it
for example : std::map<std::string, ...here go's what ??... > mystructsMap;
and say i have struct1 struct2 struct3 in my application

You can't, how would it know how much memory to allocate for an element, or even still, what would be the return type of a look-up? You'd need a new map for each value type.
One way to avoid this is to make a struct union encompassing all of your struct types.
Another solution is to make a map of void *'s instead.
In both cases, ti will be up to you, the programmer, to keep track of which struct is valid in the union returned by the map or what is represented by the void * returned.

You can derive all your structs from a common base struct and store pointers to the base struct in the map.

There is a problem with this if you don't use typedef on the struct. One would think that merely storing a pointer to the base struct would allow you to place any struct derived from base in the container. It does with one caveat. When you try to access data in the derived struct you will get garbage. Structs suffer slicing problems and because of this if you want to store all objects of type base in a container I recommend you make the base a class instead of a struct.

And now you could add SpecificObject(s) to ObjectMgr or you could add Object(s) to ObjectMgr. I would recommend that ObjectMgr be a singleton object so that only one instance of it can be created/used.

There is a problem with this if you don't use typedef on the struct. One would think that merely storing a pointer to the base struct would allow you to place any struct derived from base in the container. It does with one caveat. When you try to access data in the derived struct you will get garbage. Structs suffer slicing problems and because of this if you want to store all objects of type base in a container I recommend you make the base a class instead of a struct.

That sounds a bit off to me. You can't slice a pointer by storing it in the map, and so long as you have a way of telling what the real type the object points to is, then you can dynamic_cast it to that and everything will be accessible just fine. Remember that a struct and a class really only differ by whether their members are public or private by default, in C++.
However I'd possibly avoid a dynamic_cast by implementing the visitor pattern on the derived objects.

Other than that, perhaps a VARIANT or the boost one of those can help.

Remember that a struct and a class really only differ by whether their members are public or private by default, in C++.

Yes this is true but we ran into this about a month ago. We had a container that had base struct pointers and then added objects that were derived from the base struct. When we went to access the data we got nothing but garbage. Switching the code to classes fixed it. All we could gather is somehow it was slicing when we added to the container. Dynamic cast did not work as expected. We never found out why and didn't really waste time on it since we knew classes worked fine. We changed it, counted it a victory, and moved on. I posted that b/c under MSVC 2003 .NET and using MS's STL impl of std::map it just did not work as expected. I did not understand what was happening since we were storing base struct pointers in the map and then adding pointers to derived struct objects to it. Should have worked but none of the derived struct members were visible.

After the fact, it might be worth looking into across compilers and implementations of the STL. I still don't know what exactly was wrong and theoretically it should have worked.

Youre right that does sound weird. I can certainly understand switching from one to the other if that solved the problem. I never really used VS2003 much, I pretty much went from 2002 to 2005 and then to 2008.