Я просто прочитал о библиотеке форматирования FastFormat С++ i/o, и кажется слишком хорошим, чтобы быть правдой: быстрее, чем printf, typeafe, и с тем, что я считаю приятным интерфейсом:
// prints: "This formats the remaining arguments based on their order - in this case we put 1 before zero, followed by 1 again"
fastformat::fmt(std::cout, "This formats the remaining arguments based on their order - in this case we put {1} before {0}, followed by {1} again", "zero", 1);
// prints: "This writes each argument in the order, so first zero followed by 1"
fastformat::write(std::cout, "This writes each argument in the order, so first ", "zero", " followed by ", 1);
Это выглядит слишком хорошо, чтобы быть правдой. Есть ли улов? Были ли у вас хорошие, плохие или безразличные переживания?
Есть ли уловка с FastFormat?
В прошлый раз, когда я проверил, был один раздражающий улов:
Вы можете использовать только узкую строчную версию или широкоформатную версию этой библиотеки. (Функции для wchar_t и char совпадают - этот тип используется, это таймер компиляции.)
С iostreams, stdio или Boost.Format вы можете использовать оба.
Нашел один "улов", хотя для большинства людей он никогда не проявится. На странице проекта:
Атомная операция. Он не выписывает элементы инструкции по одному, как IOStreams, поэтому проблем с атомарностью не возникает
Единственный способ, которым я могу это видеть, - это то, что он буферизует весь вывод вызова write() сам, а затем записывает его в ostream за один шаг. Это означает, что ему необходимо выделить память, и если объект, переданный в вызов write(), выдает много выходных данных (несколько мегабайт или более), он может потреблять вдвое большую память во внутренних буферах (при условии, a-buffer-by-doubling-its-size-each-time trick).
Если вы просто используете его для ведения журнала, а не, скажем, сбрасываете огромное количество XML, вы никогда не увидите эту проблему.
Единственный другой "улов", который я вижу, это:
Очень портативный. Он будет работать со всеми хорошими современными компиляторами на С++; он даже работает с Visual С++ 6!
Поэтому он не будет работать со старым компилятором С++, например cfront, тогда как iostreams обратно совместим с конце 80-х. Опять же, я был бы удивлен, если бы у кого-нибудь была проблема с этим.
Хотя FastFormat - хорошая библиотека, есть ряд проблем с ним:
Это выглядит довольно интересно! Хороший совет, и +1 для этого!
Я играл с ним немного. Главный недостаток, который я вижу, заключается в том, что FastFormat поддерживает меньше параметров форматирования для вывода. Это, я думаю, прямое следствие того, как достигается более высокая степень безопасности, и хороший компромисс в зависимости от ваших обстоятельств.
Если вы посмотрите подробно на своей тестовой странице производительности, вы заметите, что старые добрые функции C printf -family все еще выигрывают в Linux. Фактически, единственным тестовым случаем, когда они работают плохо, является тестовый пример, который должен быть статическим конкатенации строк, где я ожидал бы, что printf будет расточительным. Кроме того, GCC обеспечивает статическую проверку типов при вызовах функций printf -style, поэтому преимущества безопасности типов снижаются. Итак: если вы работаете в Linux, и если вам нужна абсолютная лучшая производительность, FastFormat, вероятно, не является оптимальным решением.
Библиотека зависит от нескольких переменных окружения, как указано в docs.
Для некоторых людей это может быть не biggie, но я бы предпочел, чтобы мой код был как можно более автономным. Если я проверю его из источника управления, он должен работать и компилироваться. Это не будет, если для этого требуется установить переменные среды.