Есть ли «ловушка» с FastFormat?

Question

Я только что прочитал о FastFormat C ++ библиотеке форматирования ввода / вывода , и это кажется слишком хорошим, чтобы быть правдой: даже быстрее, чем printf, typesafe и с тем, что я считаю приятным интерфейсом:

// 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);

Это выглядит слишком хорошо, чтобы быть правдой. Есть ли подвох? Были ли у вас хорошие, плохие или безразличные переживания?

Answer 1

Есть ли "ловушка" с FastFormat?

В прошлый раз, когда я проверял, был один раздражающий улов:

Вы можете использовать либо версию для узкой строки или версию этой библиотеки для широкой строки. (Функции для wchar_t и char одинаковы - какой тип используется для переключения времени компиляции.)

С iostreams, stdio или Boost.Format вы можете использовать оба.

Answer 2

Найден один «улов», хотя для большинства людей он никогда не проявится. Со страницы проекта:

Атомная операция. Он не записывает элементы операторов по одному, как IOStreams, поэтому не имеет проблем с атомарностью

Единственный способ увидеть, как это происходит, - это если он буферизирует весь вывод вызова write(), а затем записывает его в ostream за один шаг. Это означает, что ему нужно выделить память, и если объект, переданный в вызов write(), производит много выходных данных (несколько мегабайт или более), он может потреблять вдвое больше памяти во внутренних буферах (при условии, что он использует растущий трюк a-buffer-by-dupling-его-size-каждый раз).

Если вы просто используете его для ведения журнала, а не, скажем, для сброса огромных объемов XML, вы никогда не увидите эту проблему.

Единственный другой «улов», который я вижу:

Очень переносимый. Он будет работать со всеми хорошими современными компиляторами C ++; это даже работает с Visual C ++ 6!

Так что он не будет работать со старым компилятором C ++, таким как cfront, тогда как iostreams обратно совместим с поздними 80-ми. Опять же, я бы удивился, если бы у кого-нибудь возникла проблема с этим.

Answer 3

Хотя FastFormat - хорошая библиотека, с ней есть ряд проблем:

• Ограниченная поддержка форматирования, в частности, следующие функции не поддерживаются:
  • Лидирующие нули (или любые другие незаполненные отступы)
  • Восьмеричное / шестнадцатеричное кодирование
  • Ширина выполнения / спецификация выравнивания
• Библиотека довольно большая для относительно небольшой задачи форматирования и имеет еще большую зависимость (STLSoft).

Answer 4

Это выглядит довольно интересно! Хороший совет, и +1 за это!

Я немного поиграл с этим. Основной недостаток, который я вижу, заключается в том, что FastFormat поддерживает меньше параметров форматирования для вывода. Это, я думаю, прямое следствие того, как достигается более высокая безопасность типов, и хороший компромисс в зависимости от ваших обстоятельств.

Answer 5

Библиотека зависит от пары переменных среды, как указано в документах .

Для некоторых это может быть не так уж важно, но я бы предпочел, чтобы мой код был максимально автономным. Если я проверю это из системы контроля версий, она должна работать и компилироваться. Не будет, если потребуется установить переменные окружения.

Answer 6

Если вы посмотрите подробно на его страницу производительности, вы заметите, что старые добрые функции семейства C printf все еще выигрывают в Linux. Фактически, единственный тестовый случай, когда они работают плохо, это тестовый случай, который должен быть конкатенацией статических строк, где я ожидал бы, что printf будет расточительным. Кроме того, GCC обеспечивает статическую проверку типов при вызовах функций в стиле printf, поэтому преимущества безопасности типов уменьшаются. Итак: если вы работаете в Linux и , если вам нужна абсолютная лучшая производительность, FastFormat, вероятно, не является оптимальным решением.