три типа интерфейсов:
- Через parameter pack
- Через std::tuple
- Через std::array
- Может ещё через что-то в будущем.
Что ты предлагаешь? В каждом месте тыкать std::apply или ещё чего другого по потребности?
Надо перестать выдумывать кривые велосипеды и использовать структуры для RGB 🤦♂️
Если серьёзно, то не делать же реально? https://t.me/ProCxx/598612 Была идея написать этот интерфейс, чтобы универсально работало для RGB/RGBA и не выглядело слишком громоздко.
rbg/rbga это тупо массивы из 3 / 4чисел
Ну, вот я подумал, что мне предлагают значит для вот этого отдельно писать классы.
Что непонятно? не надо тащить туплы туда, где они нафиг не нужны
Ок, т.е. нужно просто прикрутить массив на вход и выход, запилить https://t.me/ProCxx/598612 и будет заебись?
Откуда я знаю, что вам там "нужно", я как-то без RGB велосипедов обхожусь
Да, почему нет? Будет class Color c uint8_t полями r,g,b,a std::vector<Color> и можете его кастовать к чему угодно, std::vector<Color>& или вообще uint8_t*
Я может плохо объяснил, но у меня нету задачи написать что-то конкретное. По сути я просто придумываю странные задачки и пытаюсь из решить используя что-то новое, с чем я мало работал. Вот этот пример с RGB я пытался реализовать generic интерфейс для того чтобы нормализовать цвета. Первое что получилось для RGB: https://t.me/ProCxx/598612 Начал думать, а можно ли не писать это безобразие. Вот так и пришёл к текущему решению.
Ясен пень что можно на каждый примитивный тип написать огромный хедер на 1000+ строчек, как в глм под каждый вектор, но что мне даст, — непонятно. Если оно так нужно, то действительно можно глм подрубить и не писать велосипед.
Ок. Я пропустил контекст вопроса. В том же SDL сделано так же, массив стркутур r,g,b,a. В glm уже можно подать массив rgba предварительно кастануть к принимаемому типу. Проблем не должно быть.
Использовать glm - это как писать единицы измерения из СИ рядом со значениями физических величин (как противовес использованию собственных попугаев). Сразу понятно что это и про что. Семантика известна читающему код. Ему не требуется лезть в частную собственноручную (возможно багованную) реализацию подмножества glm (это практически определение костыля), чтобы прочитать и понять, какие у этого поделия свойства.
С таким подходом можно вообще не пытаться ничего нового писать. Так и будем до конца веков пользоваться C++11 и template specialization'ами из GLM'а. Нет, я конечно когда буду писать что-то серьёзное, а не поделку в свободное время, конечно подрублю его, но хотелось бы периодами пытаться что-то выдумать паралельно тыкая что там добавили господа стандартизаторы.
Обсуждают сегодня