Пишу, по большей части, про историю, свою жизнь и немного про программирование. Живу в Казани.

Си++: форматированный вывод (продолжение)

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

Мои приключения c форматированным выводом в Си++ до сих пор не закончились, оказалось, что последний вариант обёртки над std::snprintf в одном из компиляторов не собирается с одним из видов аргументов, пришлось его обернуть в std::cref.

Умные люди в комментариях советуют перейти на внешнюю библиотеку fmt и я уже сделал подход к снаряду, но под mingw у меня сборка пока не заработала. Завтра попытаюсь ещё раз — хочу подключить библиотеку подмодулем к своему репозиторию встроить компиляцию в процесс сборки своего проекта. Мне кажется, что я делаю всё правильно, а вот mingw так не кажется, попытаюсь завтра побороть.

2 комментария
Сергей Чебан 9 мес

Не спеши.

  1. Проблема в том, что ты пока недостаточно хорошо знаешь язык. Ты пытаешься делать достаточно сложные вещи, они закономерно не работают, и виноваты в этом не компиляторы.
  2. Одна из особенностей экосистемы C++ заключается в том, что она не предоставляет готовые решения для кучи актуальных программистских задач. Поставив компилятор, ты не найдёшь в комплекте ни средств для работы с HTTP, ни криптографии, ни логгинга. Всё это есть, но процесс интеграции сторонних библиотек в свой проект настолько нетривиален, что иногда проще плюнуть и реализовать нужное самостоятельно.
  3. Экосистемы Windows и Unix сильно отличаются друг от друга. Ты замахнулся сразу на обе, не зная толком ни одной, ни другой. Конечно, тебе тяжело.

Почему оно так? Да потому что корни C++ растут из 1970 года и ещё более ранних времён. Многие подходы, принятые в те времена, сейчас устарели, но уйти от них не получается, потому что на них держится пятидесятилетний хвост legacy. Ты-то в своём проекте можешь сделать всё по-новому, но кто будет дорабатывать написанную в 1995 году библиотеку zlib? Ото ж.

Что касается библиотеки fmt, есть смысл начать с чтения документации: https://fmt.dev/latest/usage.html. Там предложены разные варианты установки этой библиотеки (а в процессе чтения выяснится, что C++ существует не сам по себе, а в экосистеме, в которую, кроме него, входят cmake и пр.).

Евгений Степанищев 9 мес

Мне тут в личке грозятся сделать пулл-реквест и притащить conan, cmake и fmt. Что же, посмотрю )

В моей попытке перехода на fmt я из Makefile вызывал cmake, в документации такого способа нет, пришлось самому сколхозить, но путь с переходом на cmake мне нравится больше, конечно, просто всё сразу я не осилю, хотел есть слона по частям.

Сергей Чебан 9 мес

Обычно всё же не из make вызывают cmake, а наоборот. Т. е. workflow примерно такой:
mkdir build
cd build
cmake .. # создаёт makefile или его эквивалент в зависимости от платформы и опций
cmake —build . # вот это можно заменить на make или msbuild

А если у тебя уже есть makefile, к которому ты привязан, то вся история с cmake теряет смысл: его задача — обеспечить сборку проекта там, где нет make, а есть вместо него что-то другое.

Евгений Степанищев 9 мес

Мне проект достался с Makefile, да. Я его только причесал, а то там никакой автоматизации не было — файлы просто перечислялись внутри. fmt идёт с cmake, чтобы компилировать одной командой, я вызываю cmake из Makefile.

Надо бы перейти на cmake, наверное, но несмотря на то, что я на нём писал несколько программ, файлы сборки я на нём не писал и пока не знаю как это делается. Впрочем, как я писал выше, мне обещают пулл-реквест на эту тему.