Мильён структур и типов

[OKTA]

Товарищи, посоветуйте, как лучше сделать.
Имею библиотеку, которая выдает структуру, в которой лежит указатель на одну из 4 структур других типов, в каждой из которых лежит несколько полей данных, которые могут быть нескольких типов(около 10 разных). Принимая такие структуры, мне надо засунуть из в таблицу, но перед этим хочу создать свой контейнер для их хранения. Но проблема в том, что я могу узнать, что лежит в каждой отдельной структуре, лишь когда ее открою и так же типы данных вижу только в самый последний момент (первым полем в каждой структуре - идентификатор типа данных остальных полей). Как лучше сделать, чтобы было удобно хранить и избавить себя от миллиона явных преобразований типов? Только через шаблоны?  

[Bepec]

Ммм... А в чем проблема? у вас есть структура. Возьмём класс, добавим ему возможности иметь неизвестное количество полей неизвестного формата (ну ваших 10 разных). И при добавлении будет инициализировать его вашими структурами. В результате получится массив указателей на классы структур. Или указатель на главную ноду.

PS вроде бы стандартный такой древовидный подход

PPS 1 класс для хранения и шаблонный класс для типов. Хотя хз какие у вас там типы, мб шаблон больно вычурный получится.

[Old]

2ОКТА А как вы эту древовидную структуру хотите в таблице отображать?

[OKTA]

2ОКТА А как вы эту древовидную структуру хотите в таблице отображать?

Да это не особо древовидная структура. Если грубо на словах, то опуская все тонкости имеем 4 типа контейнеров -  array/range/enumeration/one_value, в каждом из которых тип данных может быть любым из встроенных типов и еще нескольких пользовательских. Т.е. каждая строка таблицы - это один контейнер. Видимо другого пути, как и советует Верес, нет - создать шаблонный класс c вложенным шаблоном (или как это сказать по-русски - nested template) для контейнеров, проинициализировать их и засунуть в массив, не забыв еще и добавить тип контейнера и тип данных в каждом контейнере. А когда будем работать с ним в интерфейсе - открываем контейнер, смотрим на его тип и тип данных и шпарим.

[Old]

Покажите на примере такой шаблонный класс.

Мне вот кажется, что все это можно положить в список контейнеров:

Код

C++ (Qt)
QList<Container*> items;
 

А Container это базовый класс от которого происходят контейнеры: array, range, enumeration и one_value.

[Johnik]

может union ?

[OKTA]

Union не даст никаких преимуществ я думаю.
Начал так  - 4 структуры и класс контейнера. Ну и дальше да, в QList их.
Делать базовый класс для контейнеров пока поостерегся - у структур нет ничего общего, кроме одного поля, определяющего тип.
Приму все замечания  

Код:

template <class T> struct onevalue {
    //

    ushort itemType;
    T item;

};

template <class T, template <class> class P >
class Container
{
public:
    P<T> data;
};

Container <int, onevalue> testContainer;

Это пока так, заготовка, в класс еще надо добавить несколько полей..

[OKTA]

Ан нет, твоя правда Old..
Надо делать класс, а в нем уже все преобразования делать - в QList так просто не подсунешь шаблонный класс.

[Old]

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

[OKTA]

Да, я уже иду к этому 
Подумал, что чтобы не мучиться с хранением, буду использовать QVariant, а уже в таблице в зависимости от типа данных принимать решение, как их визуализировать 

[Old]

а уже в таблице в зависимости от типа данных принимать решение, как их визуализировать 

Так это же прямой путь к 100500 switch & cast. Вроде от этого хотели уйти.

[OKTA]

В любом случае придется использовать switch + cast, чтобы сохранить данные в своих контейнерах 

[Old]

В любом случае придется использовать switch + cast, чтобы сохранить данные в своих контейнерах 

Ну это один раз. А так switch + cast будет в каждом втором методе.

[OKTA]

Попробую обмозговать вашу идею 

[OKTA]

Ешкин кот, придется убить эту идею с преобразованием и хранением данных и использовать их в исходном виде.. Выяснилось, что придется еще реализовывать задачу установки новых значений, а для этого надо, чтобы данные были в тех же формтах, в каком приходят из библиотеки. Так что проще реализовать универсальную модель и универсальный интерфейс для отображения и изменения.