I\'m designing a simple Array
class with the capability of holding any type of object, like a vector that can hold multiple types of data in one object. (This i
dynamic_cast<>(), when used on a pointer, can be used to check whether the cast is actually possible since it returns NULL when the types don't match.
However, you'll probably want to reconsider your setup; dynamic_cast isn't something you'll want to use if you can avoid it, and having cascades of "if object-is-type1 then do this; else if object-is-type2 then do that; else if object-is-type3..." is almost always a sure sign of bad design.
Using auto in your get_element is probably your trick of getting around the problem that you don't know what the type will be -- that won't work, though. The compiler still has to know the return type; it cannot change at runtime.
EDIT: you might also go a step back and ask yourself whether you REALLY need an array that can store "anything". I've used Objective-C for a long time, and it's basically built around the idea that everything is just an "object" and people can call anything on anything, it's all sorted out at runtime. However, I found that actual uses of this are rare... and for containers in particular, I find that every NSArray that I use only has objects of one type, or maybe of a common base class, but not actually distinct, unrelated classes.