Комментарии 10
Да, какая все-же маленькая и понятная программа, когда она написана с использованием классического (предусмотренных дизайном языка) рантайм-полиморфизма, и какая большая и непонятная на шаблонах (и не предусмотренных изначально дизайном языка шаблонных вычислениях) :)
Подождём год-другой, когда C++14 нормально будет поддерживаться компиляторами, — там уже полиморфные лямбды вернут чистоту и прозрачность. А в 2017, глядишь, и вообще будет не C++, а хаскелл с нечеловеческим лицом.
А кто хотел функциональщину в начале 2000-х, те уже тогда писали чёрте-что на boost::bind, boost::lambda, boost::phoenix и других веломотосипедах.
А кто хотел функциональщину в начале 2000-х, те уже тогда писали чёрте-что на boost::bind, boost::lambda, boost::phoenix и других веломотосипедах.
Простите за вопрос, но меня как олд-скул С++ программиста в таких статьях всегда интересует, каково практическое применение этих вещей? Самый первый пример с рантаймовым полиморфизмом понятен и достаточно прост.
В чём выигрыш последнего примера, который вместо этого создал массу сложных конструкций?
Я правда хочу разобраться и понять, стоит ли оно всё того, потому что на данный момент польза для меня не очевидна. Возможно, после очередного объяснения меня озарит, и я тоже буду пользоваться всей выразительной мощью последних нововведений.
В чём выигрыш последнего примера, который вместо этого создал массу сложных конструкций?
Я правда хочу разобраться и понять, стоит ли оно всё того, потому что на данный момент польза для меня не очевидна. Возможно, после очередного объяснения меня озарит, и я тоже буду пользоваться всей выразительной мощью последних нововведений.
Я так понимаю, смысл в том, чтобы в функции finish можно было проверить правильность использования шаблонов на этапе компиляции. Но в том примере использования, который был в изначальном вопросе, это, конечно, излишне.
Ну, иногда отказ от рантайма даёт изрядный выигрыш в скорости.
Пример из моей рабочей задачи: распознавание речи.
Декодер конструируется с тремя компонентами: акустическая модель (двух видов, с энергичным и ленивым вычислением вероятностей акустики), граф языковой модели (трёх видов, прекомпилированный двумя способами и компилируемый на лету — он медленнее, но компактнее) и аккумулятор распознанных гипотез (быстрый-глупый в виде префиксного дерева и тщательный в виде бора).
Выбор компонентов задаётся из конфига. Это делается единожды при запуске, а вот дальше декодер в течение нескольких минут или часов молотит, как двигатель спортивного мотоцикла.
Никакой шарп и окамл не обеспечат ту производительность, которая получается на С++ без виртуальных функций.
Поэтому — фабрика класса декодера выглядит именно так, с продолжениями. Только она писалась с оглядкой на старый gcc, поэтому всей этой модной красоты с лямбдами там нет.
Пример из моей рабочей задачи: распознавание речи.
Декодер конструируется с тремя компонентами: акустическая модель (двух видов, с энергичным и ленивым вычислением вероятностей акустики), граф языковой модели (трёх видов, прекомпилированный двумя способами и компилируемый на лету — он медленнее, но компактнее) и аккумулятор распознанных гипотез (быстрый-глупый в виде префиксного дерева и тщательный в виде бора).
Выбор компонентов задаётся из конфига. Это делается единожды при запуске, а вот дальше декодер в течение нескольких минут или часов молотит, как двигатель спортивного мотоцикла.
Никакой шарп и окамл не обеспечат ту производительность, которая получается на С++ без виртуальных функций.
Поэтому — фабрика класса декодера выглядит именно так, с продолжениями. Только она писалась с оглядкой на старый gcc, поэтому всей этой модной красоты с лямбдами там нет.
Насчет виртуальных функций. Неужели так все плохо с ними, что приходится сводить к такому статическому полиморфизму? Компиляторы же умеют проводить девиртуализацию. Хотелось бы услышать реальные цифры с реальных проектов, а не про сферического коня в вакууме, если можно.
Всё не просто плохо, а ужасно.
Реальные цифры приводить не буду, потому что опыты по девиртуализации ставил давно, и ломать всё обратно — никакого желания нет. Но прирост скорости — в два раза.
Для любопытствующих — могу предложить закопаться в библиотеку OpenFST. Там все фасады объектов — на виртуальных функциях, но все потроха — девиртуализированы. Из-за этого там трёхэтажные вызовы получаются, которые в дебажной сборке адски тормозят, а в релизной после инлайна летают.
Реальные цифры приводить не буду, потому что опыты по девиртуализации ставил давно, и ломать всё обратно — никакого желания нет. Но прирост скорости — в два раза.
Для любопытствующих — могу предложить закопаться в библиотеку OpenFST. Там все фасады объектов — на виртуальных функциях, но все потроха — девиртуализированы. Из-за этого там трёхэтажные вызовы получаются, которые в дебажной сборке адски тормозят, а в релизной после инлайна летают.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статически типизированные продолжения