В стародавние времена были живые порталы с флеш-играми (а затем и html5) обвешанные с хидера до футера рекламой, в играх тоже вставлялись рекламы. Тем они и жили скупая игры на разных условиях с аукционов типа FGL или лично из рук в руки. Коротко как-то так.
Сценарий проверки наличия чего-либо в контейнере, например. Весь этот гетерогенный поиск в равной степени относится и к “map”, просто на set’е показывать удобнее.
Даже в таймлайн-анимациях нужно знать куда и как крутить/переносить, с ограничениями и весами. Скелет эту информацию имеет. Без неё может получиться не совсем то, что ожидается, мягко говоря, кроме каких-то частных и ограниченных случаев, конечно.
В общем случае их не получается блендить банально из-за отсутствия связей между фрагментами разных анимаций. В скелетной анимации эту связь организует нам сам скелет, мы знаем что и куда должно блендиться. Во флеш-анимации у нас будут просто куча разрозненных фрагментов. Но это не отрицает, конечно, что в частном случае можно изголяться над всей этой структурой, организуя поверх какие-то вариации на эту тему. Возможно, получится троллейбус из буханки хлеба, но может тогда стоит просто взять скелетку?
P.S.
Про структуру и внутренности swf-формата будет информация в следующей части.
Можно, но добавь перфект форвардинг (прямую передачу?), возможности оборачивать функциональные объекты и т.д и получится одна гигантская нечитаемая функция :) Ну и с количеством аргументов функции ты с другой стороны зашёл, чем в kari.hpp. и прозрачно применять вложенные каррированные функции не получится. В общем с нужной допилкой получится по строчкам тоже самое, что и в моём подходе.
Очень простой ответ: каррирование в исконном виде служит скорее чисто математическим целям (читать в сторону комбинаторной логики), на практике же даёт, например, возможность частичного применения, как описано в этой статье. А вот частичное применение, в свою очередь открывает путь к построению более сложных абстракций и концепций из области функционального программирования, что выливается в банальное сокращение объёмов кода при их написании. Но и без более высоких абстракций может принести пользу, там где используется всеми известный std::bind, например, который тоже является средством частичного применения.
Хорошая штука, да. Вариадик бинд проще сделать правильно идеологически, потому что ты чётко задаёшь количество аргументов и их место при связывании. С библиотекой из статьи так красиво не получится :(
К сожалению, стоило, в противном случае мне пришлось бы писать там тип лямбды, что невозможно без decltype и auto, либо выносить лямбду в отдельный явный функтор, что ещё больше запутало бы. Еще как вариант там можно было бы написать std::function<int(int)>, но это была бы совсем другая история :)
Всё так, constexpr, decltype(auto), ну и из стандартной библиотеки пара функций, которые можно заменить на свои аналоги. + Было интересно именно для 14ого, т.к generic лямбды появились и хотелось бы, чтобы с ними тоже всё работало. Но можно поковырять и сделать поддержку 11-ого, да, без некоторых фич типа constexpr'а.
Всё в нём так, но когда шумели обсуждения — многие называли такой подход словами аля «токсичный», что и заставило вспомнить эту статью после прочтения текущей.
Конечно, так как оценивают работы и голосуют сами участники джема, то нужно обеспечить запускаемость на их же компьютерах. Сильно приветствуются веб-билды (по опыту), ибо тогда не нужно ничего отдельно качать, ставить и захламлять машину. Запустил, проверил, поставил оценку. Многие делают кучу билдов на выбор, WIN, MAC, WEB, к примеру.
Оно будет работать (половина функций в случае «LINQ for iOS»), вопрос Как и в цене за использование, а цена — это куча аллокаций на ровном месте, просаженный перфоманс, опять же на ровном месте, если вам это позволительно, то пожалуйста, используйте, просто будьте осторожны. Одно неверное движение и может случиться плохое, а потом эти страшные сны с участием GC, часы профайлинга, переписывания кусков кода и прочее.
В стародавние времена были живые порталы с флеш-играми (а затем и html5) обвешанные с хидера до футера рекламой, в играх тоже вставлялись рекламы. Тем они и жили скупая игры на разных условиях с аукционов типа FGL или лично из рук в руки. Коротко как-то так.
Просто упрощённая калька требований стандарта к обобщённой(!) специализации этого функционального объекта.
Сценарий проверки наличия чего-либо в контейнере, например. Весь этот гетерогенный поиск в равной степени относится и к “map”, просто на set’е показывать удобнее.
Согласен, стоило бы дописать пример с неупорядоченными контейнерами, но зная о такой возможности после прочтения заметки можно найти нужные примеры.
Полиморфных компараторов ещё не завезли и вряд ли завезут :-) Так что темплейтный using как решение вполне себе работает.
P.S.
Про структуру и внутренности swf-формата будет информация в следующей части.
В геймдеве, например.
Очень простой ответ: каррирование в исконном виде служит скорее чисто математическим целям (читать в сторону комбинаторной логики), на практике же даёт, например, возможность частичного применения, как описано в этой статье. А вот частичное применение, в свою очередь открывает путь к построению более сложных абстракций и концепций из области функционального программирования, что выливается в банальное сокращение объёмов кода при их написании. Но и без более высоких абстракций может принести пользу, там где используется всеми известный
std::bind
, например, который тоже является средством частичного применения.К сожалению, стоило, в противном случае мне пришлось бы писать там тип лямбды, что невозможно без
decltype
иauto
, либо выносить лямбду в отдельный явный функтор, что ещё больше запутало бы. Еще как вариант там можно было бы написатьstd::function<int(int)>
, но это была бы совсем другая история :)