Russian Qt Forum
Март 28, 2024, 23:51 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 2 3 [4] 5 6   Вниз
  Печать  
Автор Тема: оператор [] для union  (Прочитано 35844 раз)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #45 : Май 14, 2018, 13:13 »

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

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

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

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

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

Сообщений: 858



Просмотр профиля
« Ответ #46 : Май 14, 2018, 13:41 »

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

Вроде это всё обсуждали много месяцев назад в этой теме. Есть ли смысл повторяться? Вы же всё равно всё сделаете по своему Улыбающийся. Old чуть выше вкратце написал, какой должна быть архитектура. Именно это я в той теме и пытался растолковать.
« Последнее редактирование: Май 14, 2018, 13:52 от ViTech » Записан

Пока сам не сделаешь...
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #47 : Май 14, 2018, 15:35 »

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

Вы же всё равно всё сделаете по своему Улыбающийся.
Так других реальных предложений не видно. Об "архитектуре" калякать хорошо, а доходит до дела ... "нужно знать задачу" Улыбающийся Что практически означает - делать человек ничего не хочет, ото как-то сделано - и пусть работает, а я пока книжечки почитаю, поумничаю  Улыбающийся 
Записан
deMax
Хакер
*****
Offline Offline

Сообщений: 600



Просмотр профиля
« Ответ #48 : Май 14, 2018, 17:39 »

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

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

А вот такой вариант, чем плох:
Цитировать
templete <T> class value { T get(Time) }

class Object3D {
 value<float> x,y,z;
}
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4349



Просмотр профиля
« Ответ #49 : Май 14, 2018, 18:09 »

Давайте начнем с простого, что хотите написать, а мы подумаем как сову на это натянуть.
Мы все вместе взятые вряд ли сможем сравнится в этом с автором темы. Улыбающийся
Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #50 : Май 14, 2018, 21:23 »

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

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

Пока сам не сделаешь...
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #51 : Май 15, 2018, 05:05 »

А вот такой вариант, чем плох:
Цитировать
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;  // свои ключи у каждой компоненты
Др словами параметры могут создаваться/удаляться динамически, поэтому "универсальный контейнер" придется делать так или иначе. Кстати подобная задача возникает у меня далеко не в первый раз, она вовсе не является чем-то необычным, тем более "костылем"
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #52 : Май 15, 2018, 17:34 »

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

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

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

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

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

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

Сообщений: 11445


Просмотр профиля
« Ответ #53 : Май 16, 2018, 13:25 »

Ну а собсно, чем обычный (ку)вариант-то плох? Кажется, 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
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4349



Просмотр профиля
« Ответ #54 : Май 16, 2018, 13:48 »

Не понял, а почему сразу стих бурный поток критики?
А где он стих?
Это отвратительное решение из-за отвратительной универсальности варианта.
Еще одно подтверждение того, что универсальные контейнеры, такие как вариант, зло.
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #55 : Май 16, 2018, 14:07 »

Никогда не интересовался этим классом. Открываю... Ой, ну что же они "смешали все в кучу" - ведь необходимости в таких универсальных коллекциях никакой! Не понял, а почему сразу стих бурный поток критики? Ну хотя бы вот
Код
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
Хакер
*****
Offline Offline

Сообщений: 600



Просмотр профиля
« Ответ #56 : Май 16, 2018, 14:24 »

Есть такая структурка
Код
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]; должна работать
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #57 : Май 16, 2018, 14:36 »

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

Сообщений: 858



Просмотр профиля
« Ответ #58 : Май 16, 2018, 15:41 »

Никогда не интересовался этим классом.
Аналогично Улыбающийся.

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

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

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

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

Пока сам не сделаешь...
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #59 : Май 17, 2018, 06:38 »

Просьба цитированием не злоупотреблять
Очевидно, что вам это не надо - у вас будет интерполятор работать с _одним_ типом, а не быть универсальным, универсальный только интерфейс передачи. Типа
Код:
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) я не могу, т.к. нужно еще знать контрольные точки, но откуда их взять (где хранить)?
Записан
Страниц: 1 2 3 [4] 5 6   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.158 секунд. Запросов: 23.