Очередной кошмарный брейнрот момент: захотелось себе свой expected. Чужие реализации существуют, но я не хочу. На самом деле, всё просто, но я изначально всё слишком сильно переусложнил дополнительными ненужными кастами, и думал, как сделать интерфейс поудобнее, но не придумал. Плюс это примерно второй раз в жизни, когда я пишу обобщённый код со всеми этими &&, type_traits, requires и прочим.
Deducing this ещё нескоро, поэтому просто вручную передаю правильную ссылку на this в отдельные функции-реализации из & и && методов. И про переусложнения: у меня изначально зачем-то вместо просто std::invoke_result была стрёмная конструкция из decltype/declval, где я через forward_like делал для Value или Error такую же value категорию, как у экспектеда. Что-то вроде:
decltype(fn(declval<forward_like<ExpectedForward, ArgumentType>>()))
Предположительно, чтобы выбралась (или не выбралась, тоже вариант) правильная функция с правильными аргументами. Но это вроде совершенно не нужно тут.
unique_ptr просто, чтобы проверить, что там нигде ничего не копируется без необходимости, а только мувается.
void в качестве Value вроде тоже работает.
https://gist.github.com/poppyfanboy/eea054476aa1263b62027e82ffb0a1e1
Не знаю, не уверен всё же, что оно без дыр работает, я слишком тупой. И забыл, зачем оно мне изначально было нужно, что мне теперь делать с этим уродцем..
Deducing this ещё нескоро, поэтому просто вручную передаю правильную ссылку на this в отдельные функции-реализации из & и && методов. И про переусложнения: у меня изначально зачем-то вместо просто std::invoke_result была стрёмная конструкция из decltype/declval, где я через forward_like делал для Value или Error такую же value категорию, как у экспектеда. Что-то вроде:
decltype(fn(declval<forward_like<ExpectedForward, ArgumentType>>()))
Предположительно, чтобы выбралась (или не выбралась, тоже вариант) правильная функция с правильными аргументами. Но это вроде совершенно не нужно тут.
unique_ptr просто, чтобы проверить, что там нигде ничего не копируется без необходимости, а только мувается.
void в качестве Value вроде тоже работает.
https://gist.github.com/poppyfanboy/eea054476aa1263b62027e82ffb0a1e1
Не знаю, не уверен всё же, что оно без дыр работает, я слишком тупой. И забыл, зачем оно мне изначально было нужно, что мне теперь делать с этим уродцем..
>>11026
Ты нахуйа собакину cock запихал?
Ты нахуйа собакину cock запихал?
Украденная идея про то, чтобы сделать в HSV переход цвета через smoothstep вместо линейной функции, чтобы не было этих лесенок, как на втором градиенте. Чтобы наборот из RGB в этот плавный HSV конвертировать, нужна функция обратная smoothstep, она вроде аналитически выводится: https://iquilezles.org/articles/ismoothstep.
https://en.wikipedia.org/wiki/Digital_differential_analyzer_(graphics_algorithm)#Program — фиолетовая линия.
https://en.wikipedia.org/wiki/Bresenham's_line_algorithm#Algorithm — красная линия. Ужасная статья, кстати, сложно понять, что к чему, ну, так со всеми статьями на википедии. Зачастую просто вывалена куча информации как будто без попытки донести её до читателя.
Вроде полностью всегда не совпадают, но довольно близки.
Второе — прикольный алгоритм, позволяет рисовать линию исключительно через арифметику с интами. Основная идея в том, что ты пошагово идёшь вдоль прямой и выбираешь например, в этом частном случае между следующими пикселями (x + 1, y) и (x + 1, y + 1) на основе того, какой из них находится ближе (имеется в виду вертикальное расстояние, не евклидово) к прямой. За координаты пикселей берутся координаты их центров.
То, какой пиксель ближе, можно определить через знак D(x, y) := f(x + 1, y + 1/2) (геометрически — по какую сторону от прямой лежит точка, находящаяся посередине между (x + 1, y) и (x + 1, y + 1)). И тут прикол в том, что можно для точки, из которой начинается прямая, вычислить начальный D(xfrom, yfrom), а дальше в зависимости от знака D пошагово вычислять следующий Dnew через предыдущий Dold.
Ну и вместо D можно спокойно взять 2D, тогда начальный 2Dinitial = 2A + B — это инт, и все последующие 2D будут интами. И алгоритм от частного случая для первого квадранта и (x0, y0) < (x1, y1) расширяется до общего случая.
Градиент на фоне уродский, ленты одинаковых цветов эти прямо видно, наверное, из-за того, что пиксели слишком крупные, а я думал, прикольно будет выглядеть, не знаю, может быть, я математику где-то заруинил ещё.
https://en.wikipedia.org/wiki/Bresenham's_line_algorithm#Algorithm — красная линия. Ужасная статья, кстати, сложно понять, что к чему, ну, так со всеми статьями на википедии. Зачастую просто вывалена куча информации как будто без попытки донести её до читателя.
Вроде полностью всегда не совпадают, но довольно близки.
Второе — прикольный алгоритм, позволяет рисовать линию исключительно через арифметику с интами. Основная идея в том, что ты пошагово идёшь вдоль прямой и выбираешь например, в этом частном случае между следующими пикселями (x + 1, y) и (x + 1, y + 1) на основе того, какой из них находится ближе (имеется в виду вертикальное расстояние, не евклидово) к прямой. За координаты пикселей берутся координаты их центров.
То, какой пиксель ближе, можно определить через знак D(x, y) := f(x + 1, y + 1/2) (геометрически — по какую сторону от прямой лежит точка, находящаяся посередине между (x + 1, y) и (x + 1, y + 1)). И тут прикол в том, что можно для точки, из которой начинается прямая, вычислить начальный D(xfrom, yfrom), а дальше в зависимости от знака D пошагово вычислять следующий Dnew через предыдущий Dold.
Ну и вместо D можно спокойно взять 2D, тогда начальный 2Dinitial = 2A + B — это инт, и все последующие 2D будут интами. И алгоритм от частного случая для первого квадранта и (x0, y0) < (x1, y1) расширяется до общего случая.
Градиент на фоне уродский, ленты одинаковых цветов эти прямо видно, наверное, из-за того, что пиксели слишком крупные, а я думал, прикольно будет выглядеть, не знаю, может быть, я математику где-то заруинил ещё.
