- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
template<typename F, typename... CurryArgs>
struct curry {
F func;
std::tuple<CurryArgs...> tup{};
curry(F f) : func(std::move(f)) {}
template<typename... CtorArgs>
curry(F f, CtorArgs &&... args) : func(std::move(f)), tup(std::forward<CtorArgs>(args)...) {}
template<typename Tup1, typename Tup2>
curry(F f, Tup1 && tup1, Tup2 && tup2) : func(std::move(f)), tup(std::tuple_cat(tup1, tup2)) {}
template<typename... Args>
auto operator()(Args &&... args)
{
constexpr size_t have_args = sizeof...(Args) + sizeof...(CurryArgs);
constexpr size_t need_args = detail::functor_traits<F>::args_count;
if constexpr (have_args > need_args) {
static_assert(!sizeof(std::tuple_element_t<0, std::tuple<Args...>>*),
"Too many arguments.");
} else if constexpr (have_args == need_args) {
return std::apply(func, std::tuple_cat(tup, std::tuple(std::forward<Args>(args)...)));
} else {
return curry<decltype(func), CurryArgs..., Args...>(func, tup, std::tuple(std::forward<Args>(args)...));
}
}
};
int main()
{
auto f = [](int a, float b, const std::string & c) -> int {
std::cout << "Functor! a = " << a << ", b = " << b << ", c = " << c << std::endl;
return a + static_cast<int>(b);
};
std::cout << f(16, 42.1f, "Hello") << std::endl;
auto c0 = curry(f);
auto c1 = c0(16);
auto c2 = c1(42.1f);
c0(16)(42.1f)("Hello");
c1(42.1f)("Hello");
c2("Hello");
c0(16, 42.1f)("Hello");
c0(16, 42.1f, "Hello");
c1(42.1f, "Hello");
}
Хотя, справедливости ради, ответы ня нястоящем TypeScript тоже ня блещут кавайностью:
А ведь всего-то оставалось в operator()() проверить количество аргументов и при нядостатке переконструировать эту фигню...
Хотя для шаблонных функторов это бы ня сработало. Тогда насфинячить!
Поэтому совать его шаблонами в язык, где уже есть это понятие — бессмысленное занятие.
По стечению обстоятельств, иногда каррирование ещё иногда позволяет писать компактный код с коллбеками. А иногда не позволяет. И тогда некоторые извращенцы продолжают писать в pointless-free стиле с flip, on, и т.д., от чего bind бы спас.
Мораль: крестовички пусть юзают bind, и не бухтят, для их целей это более общий инструмент.
"распространен подход к выполнению большенства рутинных задач явно"
Так делают AspectJ (но джавистам велели его ругать, а приказы не обсуждаются) и NotNull аннотации JB
А где там еще кокогенерация через аннотации?
зы: ну ладно, лобок еще
Но это всё не такая метушня, как в крестах.
В крестах я могу в уткину метушню: просто принимаю указатель на T, и вызываю у него метод foo().. в джаве я так могу разве что через рефлексию.
Вот правда я не уверен, что крестоподход это хорошо, бо узнать об ошибке можно только по не очень внятным ошибкам компиляции
Алсо, нужно думать, чтобы случайно не наинстанциировать 100500 одинаковых классов
Именно поэтому и завезли концепты. Чтобы прогнать уток и вернуться к статической типизации.
У меня вот есть небольшой проект в 17-й студии, она вроде концептов не может
Как автор мема "метушня"[1], я определяю это слово как "мета-что-то". (Изначально это были метаданные в сетевом пакете, но также применимо к метапрограммированию). А кодогенерация — это она и есть, не важно на плюсошаблонах, макросах, TH, parse transforms, или printf'ом.
[1] https://govnokod.ru/20274#comment336929
вся STL же на них
пиздец разпетушило.