Да, инкрементальные и realtime сборщики. Многим можно устанавливать продолжительность максимальной паузы или запускать сборку когда удобно, что делает процесс предсказуемым
Это не функция возвращающая функцию, это описание шаблонного параметра. В синтаксисе C++ это могло бы выглядеть так
template Complex opBinary(Complex v);
У *меня* таких требований к производительности нет, в hi-load или разработке игр такие требования часто есть к определенным участкам кода. Тут даже на x86 архитектуре cache miss — 60 инструкций, что иногда многовато.
Если мы не передаем политику как объект, а создаем сами, то можем проконтролировать что никаких лишних копирований или аллокаций не было.
Основное преимущество как раз передачи типов, а не инстанционированных экземпляров в скорости — не надо вызывать конструктор копирования, нету оверхеда от виртуальных функций, хороший компилятор функторы может заинлайнить к тому-же.
Да, housekeeping'а гораздо больше становиться, по сравнению с передачей в конструктор, но иногда очень надо именно скорость.
Люди успешно собирали под ARM и MIPS
Киньте в личку пожалуйста!
Еще раз:
template<string op> Complex opBinary(Complex v);
template Complex opBinary<"-">(Complex v){…}
template Complex opBinary<"+">(Complex v){…}
template Complex opBinary(Complex v);
template Complex opBinary(Complex v){… }
template Complex opBinary(Complex v){… }
Если мы не передаем политику как объект, а создаем сами, то можем проконтролировать что никаких лишних копирований или аллокаций не было.
Да, housekeeping'а гораздо больше становиться, по сравнению с передачей в конструктор, но иногда очень надо именно скорость.
Real World Haskell
Тут, судя по вашему описанию, до простоты API Redis очень далеко
Это чья-то шутка, появившаяся, после того как некий Manu Sporny выложил свой генокод на гитхаб.