Общий контейнер для нескольких типов данных в C ++

Используя C ++, я пытаюсь создать общий контейнерный класс для обработки нескольких типов данных . Это обычная проблема с множеством решений, но я не нашел ничего более ... интуитивного, чем я привык к таким языкам, как Python или даже VB / VBA ...

Итак, вот мой сценарий:

Я создал класс DataContainer на основе boost :: any, который я использую для хранения нескольких типов данных из нескольких элементов. Я использую карту, объявленную как:

std::map<std::string, DataContainer* (or DataContainerBase*)>

, где DataContainer - это класс, который инкапсулирует объект типа:

std::list<boost::any>

вместе с удобными функциями для управления списком / доступа к нему.

Однако, в конце концов, я все еще вынужден выполнять преобразование типов вне контейнера данных.

Например, если бы я сохранил список значений int на карте, для доступа к ним потребовалось бы:

int value = boost::any_cast<int>(map["myValue"]->get());

Я бы предпочел, чтобы код повышения был полностью внутри структуры контейнера данных, поэтому мне понадобится только тип :

int value = map["myValue"]->get();

или, в худшем случае:

int value = map["myValue"]->get<int>();

Конечно, я мог бы перечислить свои типы данных и сделать что-то вроде:

int value = map["myValue"]->get( TYPE_INT );

или написать функции get (), зависящие от типа:

getInt(), getString(), getBool() ... 

Проблема с двумя последними параметрами в том, что они несколько негибкие, требуя от меня явного объявления каждого типа, который я хочу сохранить в контейнере. Решение any_cast (которое я реализовал и работает), я полагаю, в порядке, оно просто ... неэлегантно? Не знаю. Кажется, мне не нужно использовать внутреннюю механику и извне.

На мой взгляд, передача значения без объявления типа значения в вызове функции-члена DataContainer потребует решения void * (что нежелательно по очевидным причинам), а использование вызова "get ()" потребует (насколько я могу судить) функция-член «виртуального шаблона», определенная на уровне базового класса, что, конечно, недопустимо.

Как бы то ни было, у меня есть работоспособное решение, и на самом деле мое использование в этом случае достаточно ограничено по объему, так что большинство любых решений будут работать хорошо. Но мне интересно, есть ли более гибкий способ управления универсальным контейнером данных с несколькими типами, чем этот.