Да ну, что такое эффекты от анролла и инлайна по сравнению с использованием высокоуровневых абстракций, когда начинают парсить xml на лету чтобы нарисовать кнопку, да ещё и могут этот xml с диска читать. Естественно, это медленнее в рантайме, но зато удобнее в разработке и поддержке.
Да, но они ведь уже запускали что-то вроде doom, так что эта проблема уже должна быть решена. Главное, что dll для C/C++ рантайма не необходима, в других языках может быть другая ситуация.
Рантайм библиотеки-то как раз проблем нет статически прилинковать. А вот с системными вызовами уже сложнее, да и с любыми внешними библиотеками как я уже сказал.
Так а причём тут «хитро»? Вызов внешних библиотек-то явно ограничен, иначе бы ни о какой безопасности и речи не шло, а значит и будут сложности с другими платформами, и даже банально с сишными библиотеками, которые придётся пересобирать под их модифицированным компилятором и поди ещё обязательно статически линковать.
Думается мне, будут проблемы с подключением других ЯП и библиотек, т.к. безопасность. Это же не виртуализация, а статический анализ машинного кода — чтобы позвать функцию из внешней библиотеки, нужно и её проанализировать и доказать что она безопасна.
Я же специально разделяю внутреннюю поддержку кода и его внешнее использование. На вашем примере restkit, снаружи было бы проще позвать одну функцию с нужными параметрами, чем городить непонятные объекты. Изнутри же более удобно этим управлять, когда код чётко разделён по классам, плюс это более гибко.
Парсер я привёл лишь в качестве примера высокоуровневого инструмента, упрощающего код для конкретной задачи, ничто ведь не мешает использовать что-то аналогичное и для выполнения байткода.
А кто говорил, что использование ОО кода будет простым и интуитивным? :) Бонус ООП скорее в гибкости и упрощении разработки/поддержки кода, а не в простоте его использования. А для упрощения уже каждый может добавить обёрток под свои нужды.
Больших switch и т.п. иногда можно избежать с помощью более высокоуровневых инструментов, например, вместо ручного парсера использовать генераторы. Опять же, не факт что получившийся код будет проще, но его будет легче писать и поддерживать за счёт более ограниченного и чистого синтаксиса.
Тут ещё нужно чтобы мотивации хватило, иногда посмотришь на это всё и руки опускаются. Думаешь, мол, вот устроил же себе развлечение, а ведь можно было просто ещё чуть фигни добавить, никто бы и не заметил ;)
Вопрос привычки — это если к этому привыкать ;) Я лично считаю, что bind1st и т.п. это извращение и не нужно это использовать вообще.
У меня мозг выворачивается такое читать: cx = count_if (numbers, numbers+6, bind1st(equal_to<int>(),10) );
Уж лучше обычный цикл, честное слово. Либо лямбды, с ними читабельнее гораздо.
В целом согласен, но для меня самое неудобство с использованием пар связано с .first и .second, т.к. не я всё время теряюсь что есть что. В частности, когда я делаю map<int, string> idToName; то потом при обходе итератором туплю, «it->first» — это что? Ах, это id. В этом случае нужно как минимум что-то вроде .key и .value. Ещё удобнее было бы вообще .id и .name, но тут уж точно придётся структурку городить.
Но здесь-то речь о С++, а не о функциональных языках. В плюсы tuples притянули «за уши», а плюшек функциональных языков при этом нет, вот и получается фигня.
Аналогично, притянули функциональный подход с функторами, std::for_each и т.п., а те же самые лямбды только в C++0x догадались добавить. Ну и как это использовать, dummy структуры на каждый чих создавать?
Не понял, как из 5 часов, с ускорением в 3.6 раза получилось 10 минут?
Другой вопрос, учитывая, что это бэкап, нельзя ли его сразу делать инкрементальным, т.е. проскипать все сообщения до определённой даты, не получится быстрее?
А почему бинарники — это сразу dll? А из статических библиотек компиляторы могут «приинлайнить» функции при линковке. Ну а operator()(int i, int j) — то уж очевидно должна быть инлайном в .h, так что пример неудачный :)
Парсер я привёл лишь в качестве примера высокоуровневого инструмента, упрощающего код для конкретной задачи, ничто ведь не мешает использовать что-то аналогичное и для выполнения байткода.
Больших switch и т.п. иногда можно избежать с помощью более высокоуровневых инструментов, например, вместо ручного парсера использовать генераторы. Опять же, не факт что получившийся код будет проще, но его будет легче писать и поддерживать за счёт более ограниченного и чистого синтаксиса.
У меня мозг выворачивается такое читать:
cx = count_if (numbers, numbers+6, bind1st(equal_to<int>(),10) );Уж лучше обычный цикл, честное слово. Либо лямбды, с ними читабельнее гораздо.
Аналогично, притянули функциональный подход с функторами, std::for_each и т.п., а те же самые лямбды только в C++0x догадались добавить. Ну и как это использовать, dummy структуры на каждый чих создавать?
Другой вопрос, учитывая, что это бэкап, нельзя ли его сразу делать инкрементальным, т.е. проскипать все сообщения до определённой даты, не получится быстрее?