Здравствуйте, rg45, Вы писали:

S>>Это вообще зыбкая почва для споров. Если мы оперируем традиционным полиморфизмом, то надобность в отдельном форматтере для C вызывает вопросы.

R>Да только этих вопросов даже не возникло бы в случае использования функций.

Простите мне мой французский, но тут явно неравные условия. Есть конкретная fmtlib, которую можно пощупать и, поскольку она есть и опыт ее использования накоплен, то можно запросто обосрать либо ее всю, либо отдельные ее части.

А вот некий гипотетический дизайн на функциях он же идеален, в нем нет просчетов. Как можно обосрать то, чего нет?

R>Может, для начала стоит ответить на вопрос, почему вместо фунций необходимо использовать шаблон класса?

Были бы функции, можно было бы ответить. Но их нет.

У fmt::formatter, например, может быть состояние. Т.е. в процессе работы fmt::formatter::parse можно что-то сохранить/вычислить, что затем будет использовано в fmt::formatter::format. Причем наличие/отсутствие состояния совершенно прозрачно для самого fmt::format/print.

Тогда как функции stateless, и если из parse нужно что-то передать в format, то здесь уже нужно озадачиваться тем, чтобы функции были парными. Условно:

void parse(parsing_ctx &);
void format(const T & v, formatting_ctx &);

some_state parse(parsing_ctx &);
void format(const some_state & state, const T & v, formatting_ctx &);

И для меня не очевидно, что свободные функции в массовом применении в таком случае будут проще в использовании, чем специализации fmt::formatter.

R>Имхо, прикладная библиотека не должна диктовать разработчику вопросы дизайна.

Простите, но это уже демагогия. Любой существующий инструмент будет накладывать на пользователя какие-то ограничения. И с этим придется считать, возможно, и на уровне дизайна.