оператор [] для union

[Igors]

Смешать всё в кучу - не значит обобщить

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

1) Имеются 3D объекты, напр (полигонная) геометрия (сфера, куб) или источник света или еще что (всего десятка полтора типов).

2) Каждый объект имеет набор параметров. При создании объекта ему назначается дефаултный набор параметров, напр для большинства объектов по меньшей мере позиция в сцене, углы поворота и масштаб. Это набор может динамически меняться, напр подключенная к объекту текстура создаст немало своих параметров.

3) Каждый параметр - анимационная кривая, контейнер ключ (время) + значение, которое может быть вектором (XYZ), цветом (ARGB), double (signed/unsigned), int (signed/unsigned) и bool. Есть текущее время (анимации), изменяемое юзером. Каждый параметр должен уметь выдавать значение (своего типа)  для заданного времени t (может совпадать с текущим но может и нет). Обычно это значение интерполированное с помощью сплайна (опции которого хранятся в каждом эл-те контейнера)

Вот собсно и все, банально и практически стандартно в любом 3D приложении. Слушаю Ваши предложения/мысли  - как организовать параметры, какие структуры данных это должны быть.

[ViTech]

Ну ладно, архитектура - так архитектура, все равно в изначальной постановке тема себя исчерпала. Базовые сущности
...
Вот собсно и все, банально и практически стандартно в любом 3D приложении. Слушаю Ваши предложения/мысли  - как организовать параметры, какие структуры данных это должны быть.

Вроде это всё обсуждали много месяцев назад в этой теме. Есть ли смысл повторяться? Вы же всё равно всё сделаете по своему . Old чуть выше вкратце написал, какой должна быть архитектура. Именно это я в той теме и пытался растолковать.

[Igors]

Вроде это всё обсуждали много месяцев назад в этой теме. Есть ли смысл повторяться?

Помню. Правду сказать, я из этого ничего не почерпнул, все свелось к бесконечным вопросам/уточнениям пока собеседники не выдохлись Увы, такова судьба почти всех "архитектурных" тем, хорошо еще собеседник попался интеллигентный.   

Вы же всё равно всё сделаете по своему .

Так других реальных предложений не видно. Об "архитектуре" калякать хорошо, а доходит до дела ... "нужно знать задачу" Что практически означает - делать человек ничего не хочет, ото как-то сделано - и пусть работает, а я пока книжечки почитаю, поумничаю   

[deMax]

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

Давайте начнем с простого, что хотите написать, а мы подумаем как сову на это натянуть. Может вообще часть кода на golang, java.... написать.

А вот такой вариант, чем плох:

templete <T> class value { T get(Time) }

class Object3D {
 value<float> x,y,z;
}

[Old]

Давайте начнем с простого, что хотите написать, а мы подумаем как сову на это натянуть.

Мы все вместе взятые вряд ли сможем сравнится в этом с автором темы.

[ViTech]

Так других реальных предложений не видно. Об "архитектуре" калякать хорошо, а доходит до дела ... "нужно знать задачу" Что практически означает - делать человек ничего не хочет, ото как-то сделано - и пусть работает, а я пока книжечки почитаю, поумничаю   

Задачу нужно знать всегда. Взять хотя бы текущую тему: если знать задачу, то ни CData виде variant, ни тем более operator[] для union не нужны. Можно было бы время участников форума на что-то более полезное потратить. Например на то, как работать с контейнерами из элементов Value, Coord, Color по отдельности; в compile-time в составе структуры, tuple; в run-time в составе vector. Как для этого примеры операторов из моего VarData органично расширяются для контейнеров. Как можно std::any и его визитёров применять, чтобы в vector  в run-time добавлять различные контейнеры данных, если с проектированием голову особо ломать не хочется.

[Igors]

А вот такой вариант, чем плох:

templete <T> class value { T get(Time) }

class Object3D {
 value<float> x,y,z;
}

"Параметр" - вовсе не "поле данных" (объекта). Напр та же "позиция" (объекта). Казалось бы, ну она-то уж всегда существует! Это не совсем так, юзер может переключаться

Код

C++ (Qt)
value<coord> pos;  // общие ключи t (время) на 3 компоненты
...
value<float> x, y, z;  // свои ключи у каждой компоненты

Др словами параметры могут создаваться/удаляться динамически, поэтому "универсальный контейнер" придется делать так или иначе. Кстати подобная задача возникает у меня далеко не в первый раз, она вовсе не является чем-то необычным, тем более "костылем"

[Авварон]

Смешать всё в кучу - не значит обобщить

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

1) Имеются 3D объекты, напр (полигонная) геометрия (сфера, куб) или источник света или еще что (всего десятка полтора типов).

2) Каждый объект имеет набор параметров. При создании объекта ему назначается дефаултный набор параметров, напр для большинства объектов по меньшей мере позиция в сцене, углы поворота и масштаб. Это набор может динамически меняться, напр подключенная к объекту текстура создаст немало своих параметров.

3) Каждый параметр - анимационная кривая, контейнер ключ (время) + значение, которое может быть вектором (XYZ), цветом (ARGB), double (signed/unsigned), int (signed/unsigned) и bool. Есть текущее время (анимации), изменяемое юзером. Каждый параметр должен уметь выдавать значение (своего типа)  для заданного времени t (может совпадать с текущим но может и нет). Обычно это значение интерполированное с помощью сплайна (опции которого хранятся в каждом эл-те контейнера)

Вот собсно и все, банально и практически стандартно в любом 3D приложении. Слушаю Ваши предложения/мысли  - как организовать параметры, какие структуры данных это должны быть.

Ну а собсно, чем обычный (ку)вариант-то плох? Кажется, QVariantAnimation - это почти то, что вам надо. Делаете абстрактный метод variant getValue(t), дальше конфигурируете каждый параметр своей анимацией (либо список значений, либо приближение по сплайну с опорными точками), а потом вызываете getValue для каждого параметра от текущего t.

[Igors]

Ну а собсно, чем обычный (ку)вариант-то плох? Кажется, QVariantAnimation - это почти то, что вам надо.

Никогда не интересовался этим классом. Открываю... Ой, ну что же они "смешали все в кучу" - ведь необходимости в таких универсальных коллекциях никакой! Не понял, а почему сразу стих бурный поток критики? Ну хотя бы вот

Код

C++ (Qt)
    switch(interpolationType)
    {
    case QMetaType::Int:
        return castToInterpolator(_q_interpolateVariant<int>);
    case QMetaType::UInt:
        return castToInterpolator(_q_interpolateVariant<uint>);
    case QMetaType::Double:
        return castToInterpolator(_q_interpolateVariant<double>);
    case QMetaType::Float:
        return castToInterpolator(_q_interpolateVariant<float>);
    case QMetaType::QLine:
        return castToInterpolator(_q_interpolateVariant<QLine>);
    case QMetaType::QLineF:
        return castToInterpolator(_q_interpolateVariant<QLineF>);
    case QMetaType::QPoint:
        return castToInterpolator(_q_interpolateVariant<QPoint>);
    case QMetaType::QPointF:
        return castToInterpolator(_q_interpolateVariant<QPointF>);
    case QMetaType::QSize:
        return castToInterpolator(_q_interpolateVariant<QSize>);
    case QMetaType::QSizeF:
        return castToInterpolator(_q_interpolateVariant<QSizeF>);
    case QMetaType::QRect:
        return castToInterpolator(_q_interpolateVariant<QRect>);
    case QMetaType::QRectF:
        return castToInterpolator(_q_interpolateVariant<QRectF>);
    default:
        return 0; //this type is not handled
    }
 

ViTech, ну где же Ваша брызжущая ирония? А m_ax сразу как ветром сдуло 

А серьезно - да, "оно", задача-то довольно типовая. Просто у меня она намного больше, и меня не интересуют универсальность и расширяемость, поэтому хранение самих данных в виде варианта в моем случае жирновато. Также они отделались только интерполяцией, у меня так не выходит, есть сплайны с контролами.

НО общение с эти классом - только через вариант (любой его аналог), тут др ходов нет 

[Old]

Не понял, а почему сразу стих бурный поток критики?

А где он стих?
Это отвратительное решение из-за отвратительной универсальности варианта.
Еще одно подтверждение того, что универсальные контейнеры, такие как вариант, зло.

[Авварон]

Никогда не интересовался этим классом. Открываю... Ой, ну что же они "смешали все в кучу" - ведь необходимости в таких универсальных коллекциях никакой! Не понял, а почему сразу стих бурный поток критики? Ну хотя бы вот

Код

C++ (Qt)
    switch(interpolationType)
    {
    case QMetaType::Int:
        return castToInterpolator(_q_interpolateVariant<int>);
    case QMetaType::UInt:
        return castToInterpolator(_q_interpolateVariant<uint>);
    case QMetaType::Double:
        return castToInterpolator(_q_interpolateVariant<double>);
    case QMetaType::Float:
        return castToInterpolator(_q_interpolateVariant<float>);
    case QMetaType::QLine:
        return castToInterpolator(_q_interpolateVariant<QLine>);
    case QMetaType::QLineF:
        return castToInterpolator(_q_interpolateVariant<QLineF>);
    case QMetaType::QPoint:
        return castToInterpolator(_q_interpolateVariant<QPoint>);
    case QMetaType::QPointF:
        return castToInterpolator(_q_interpolateVariant<QPointF>);
    case QMetaType::QSize:
        return castToInterpolator(_q_interpolateVariant<QSize>);
    case QMetaType::QSizeF:
        return castToInterpolator(_q_interpolateVariant<QSizeF>);
    case QMetaType::QRect:
        return castToInterpolator(_q_interpolateVariant<QRect>);
    case QMetaType::QRectF:
        return castToInterpolator(_q_interpolateVariant<QRectF>);
    default:
        return 0; //this type is not handled
    }
 

ViTech, ну где же Ваша брызжущая ирония? А m_ax сразу как ветром сдуло  

А серьезно - да, "оно", задача-то довольно типовая. Просто у меня она намного больше, и меня не интересуют универсальность и расширяемость, поэтому хранение самих данных в виде варианта в моем случае жирновато. Также они отделались только интерполяцией, у меня так не выходит, есть сплайны с контролами.

НО общение с эти классом - только через вариант (любой его аналог), тут др ходов нет  

Очевидно, что вам это не надо - у вас будет интерполятор работать с _одним_ типом, а не быть универсальным, универсальный только интерфейс передачи. Типа

Код:

ColorInerpolator : public AbstractInterpolator
{
    ColorInerpolator(CurveType t, Color c1, ...) {} // опорные параметры, тип кривой
    ColorInerpolator(std::vector<Color> &colors) {} // тупо массив точек
    Variant getValue(TimeType t) override {...} // например return this->m_colors[t];
}

А дальше

Код:

void interpolateAll(TimeType t)
{
    std::map<Key, Variant> properies;
    for (auto key: requiredKeys) {
        auto interpolator = getInterpolatorForKey(key);
        properies.insert({key, interpolator->getValue(t)});
    }
}

А юзать уже соответственно
color = properties["color"].toColor();
point = properties["point"].toPoint();

[deMax]

Есть такая структурка

Код

C++ (Qt)
struct CData {
 enum Type { type_Value, type_Coord, type_Color };
 Type m_type;
 union {
   double m_value;
   double m_coord[3];
   float m_color[4];
 };
};

Спасибо

Код:

struct CData {
 enum Type { type_Value, type_Coord, type_Color };
 Type m_type;
 union {
   double m_value;
   double m_coord[3];
   float m_color[4];
 };

 Some operator[](const int &i) {
     switch (i) {
     case 1: return Some{&this->m_value, i, sizeof (m_value)};
     case 2: return Some{&this->m_coord, i, sizeof (m_coord)};
     case 3: return Some{&this->m_color, i, sizeof (m_color)};
     }
     return Some{};
 }
};

struct Some{
    void* ptr;
    int type;
    int size;

    Some operator=(const Some& other) {
        if( this->type != other.type )
            qWarning()<<"!!!";

        memcpy(this->ptr, other.ptr, this->size);
        return *this;
    }
};

трэш конечно, но может как идея подойдет(не проеверял)
dst[1]=src[1]; должна работать

[Авварон]

А, ну да, всё, что я написал подразумевает наличиет классов "точка" "цвет" и тп, а не просто массив из 3х-4х даблов (ну хотя бы чуток обернуть эти массивы)

[ViTech]

Никогда не интересовался этим классом.

Аналогично .

ViTech, ну где же Ваша брызжущая ирония?

Иронизировать над Qt уже грешно, ибо старенький он. И приходится ему тащить тяжкий груз обратной совместимости. И разрабатывался он во времена, когда в стандартной библиотеке С++ ещё толком ничего не было (до нашей эры/С++11), не говоря уже о возможностях самих компиляторов. И приходилось кучу костылей для него велосипедить.

Архитектурой Qt я не восторгаюсь, скорее наоборот. Хотя понимаю, почему она такая (возможности компиляторов/std на момент разработки, обратная совместимость, поддержка кучи платформ). Менять архитектуру и перепроектировать классы Qt теперь никто не будет, жить ему с этим до конца дней своих. Потому как если всё менять, то это уже и не Qt будет .

С другой стороны, на этом этапе, насколько я понял, у Вас была возможность начать всё с довольно чистого листа. Когда нормальные компиляторы уже C++14 полностью поддерживали (и можно было даже на C++17 закладываться), в std больше полезного стало (можно boost не тащить), поддержка шаблонов лучше, велосипедов меньше, трава зеленее, Букварь толще, паттерны стройнее... лепота (хотя есть куда ещё стремиться). Так что, на мой взгляд, можно было для той задачи решение получше придумать . Посему позволяю себе иногда поиронизировать .

[Igors]

Просьба цитированием не злоупотреблять

Очевидно, что вам это не надо - у вас будет интерполятор работать с _одним_ типом, а не быть универсальным, универсальный только интерфейс передачи. Типа

Код:

ColorInerpolator : public AbstractInterpolator
{
    ColorInerpolator(CurveType t, Color c1, ...) {} // опорные параметры, тип кривой
    ColorInerpolator(std::vector<Color> &colors) {} // тупо массив точек
    Variant getValue(TimeType t) override {...} // например return this->m_colors[t];
}

Здесь предполагается что вход интерполяции - просто TimeType t который QEasingCurve умеет посчитать. Однако для Безье-подобных кубических сплайнов это не так, там значение вычисляется

Код:

value = point0 * k0(t) + ctl0 * k1(t) + ctl1 * k2(t) + point1 * k3(t);

Где
t - время на сегменте (от 0 до 1)
point0, point1 - значения в начале и конце сегмента (напр QColor)
k(t) - интерполяционный полином (обычно Эрмит или Бернштейн)
ctl0, ctl1 - настраиваемые параметры (контрольные точки) сплайна

Вот этих настраиваемых параметров я в Qt реализации не увидел (ну может плохо смотрел). Это числа double которые юзер может менять подстраивая таким образом кривизну (собсно поэтому Безье сплайны так популярны). Числа свои для каждого "канала", напр для одного double - одно число, для координаты 3, для цвета 4. Таким образом каждый канал интерполируется независимо, хотя коэффициенты полинома одинаковы.

Ну и тут получается изрядная котовасия - просто так интерполировать "голые" значение (напр QColor) я не могу, т.к. нужно еще знать контрольные точки, но откуда их взять (где хранить)?