А можете привести участок кода где вы его используете как есть? Мне не понятно как можно получать 150 000й элемент массива и при этом наперёд знать его тип.
А можно как то получить тип (std::type_index) из вашего dynamic_tuple по индексу? Ну то-есть получить элемент по индексу, а потом в зависимости от его типа по своему обработать (как с std::vector< std::variant<...> >).
Возможно можно как-то переделать на матчинг по нескольким параметрам (вас наверное деструктуризация интересует). Но! Рекомендую к ознакомлению http://cppnow2016.sched.org/event/6Sfb (когда появится конечно).
Тем, что вы должны прямо «здесь и сейчас» обработать тип. Передать его дальше для обработки нельзя...
Вы имеете ввиду что теряется информация о типе? Если да, то я не понимаю как.
Банальный for_each?
Извините, но я считаю что это разные вещи. Здесь нужен отдельный алгоритм прохода по кортежу, и он у меня есть. Так же как и Hana'вский он принимает на вход кортеж, и лямбду. В лямбде можно уже использовать pattern matching.
Более того — текущий pattern matching можно использовать в Hana::for_each как есть:
hana::for_each(hana::make_tuple(0, '1', "234", 5.5), [&](auto x) {
match(x
,[](std::string value) { cout << "This is string"; }
,[](int i) { cout << "This is int"; }
,[](auto a) { cout << "This is default"; }
);
});
Hana — это библиотека. И мне она не нравится. Прежде всего по тому что там свои кортежи.
Здесь же описана конкретная конструкция. Мне кажется это как сравнивать STL и конкретно взятый алгоритм.
Вот самый очевидный пример который я придумал. В С++17 введена конструкция constexpr if. Она позволяет выполнять ветвления на этапе компиляции. Например:
А чем менее удобная? Визуально в Hana писанины больше. + Я не пробовал, но почти уверен что если начать тянуть эту часть из Boost'a пара мегабайт (как минимум) кода обеспечена.
1) А как включить софтверный рендерер в QML?
2) А как же кастомные компоненты (написанные на С++, расширяющие QQuickItem) будут, извините, работать при влюченном софтваном рендерере? [напомню что QQuickItem возвращает текстуру, а на текустуре обычно малюют с помощью QOpenGLFunctions, которые есть по сути OpenGL ES 2.0]
Как оно вообще работает? Можно где то по конкретнее об этом почитать?
А можете привести участок кода где вы его используете как есть? Мне не понятно как можно получать 150 000й элемент массива и при этом наперёд знать его тип.
А можно как то получить тип (
std::type_index) из вашего dynamic_tuple по индексу? Ну то-есть получить элемент по индексу, а потом в зависимости от его типа по своему обработать (как сstd::vector< std::variant<...> >).Да, похоже. Насчет вашего "тонкого паттерн матчинга", gcc >=4.9.x и VS поддерживают то что вы хотите уже здесь и сейчас http://coliru.stacked-crooked.com/a/61b8afdb8e54d9af
Все же ближе к этому https://habrahabr.ru/post/282630/?reply_to=8875810#comment_8873766
To DISaccount:
А как вы решали дело с классами? Через указатель на член класса &ClassName::test1?
Мда действительно, просто то таки посмотрел на эту перегрузку другими глазами.
Возможно можно как-то переделать на матчинг по нескольким параметрам (вас наверное деструктуризация интересует). Но! Рекомендую к ознакомлению http://cppnow2016.sched.org/event/6Sfb (когда появится конечно).
К сожалению, теперь я не могу понять что тут вообще происходит...
Вы имеете ввиду что теряется информация о типе? Если да, то я не понимаю как.
Извините, но я считаю что это разные вещи. Здесь нужен отдельный алгоритм прохода по кортежу, и он у меня есть. Так же как и Hana'вский он принимает на вход кортеж, и лямбду. В лямбде можно уже использовать pattern matching.
Более того — текущий pattern matching можно использовать в Hana::for_each как есть:
Hana — это библиотека. И мне она не нравится. Прежде всего по тому что там свои кортежи.
Здесь же описана конкретная конструкция. Мне кажется это как сравнивать STL и конкретно взятый алгоритм.
Вот самый очевидный пример который я придумал. В С++17 введена конструкция constexpr if. Она позволяет выполнять ветвления на этапе компиляции. Например:
Без constexpr if вам бы пришлось в данном случае три дополнительные функции:
C pattern matching (как реализовано в статье):
С увеличением сложности разница ещё более увеличивается. Основной плюс как по мне что код получается не размазанным по всему файлу.
Этот stylesheet случайно не тот что только в текстовом редакторе цвета меняет, а все остальное остается дефолтным?
Дык оно ж платное, ядрен батон!
Помойму, оно не очень совместимо с С++ компоннентами (через QQuickItem).
И примеров нет…
1) А как включить софтверный рендерер в QML?
2) А как же кастомные компоненты (написанные на С++, расширяющие QQuickItem) будут, извините, работать при влюченном софтваном рендерере? [напомню что QQuickItem возвращает текстуру, а на текустуре обычно малюют с помощью QOpenGLFunctions, которые есть по сути OpenGL ES 2.0]
Как оно вообще работает? Можно где то по конкретнее об этом почитать?
Как по мне — набор слов без смысла :)
Обрабатываете изображение — а оперируете матрицами… Для ламеров, в двух словах о получении матриц было бы не плохо.
И что само ужасно! Не строчки кода!!!
Как жить? Как жить я вас спрашиваю, господа? :)
Тогда нужны специальные шрифты под Windows…