суббота, 29 октября 2022 г.

[prog.c++] Дикая идея о том, как можно было бы еще улучшить fmtlib и std::format

Навеяно срачем на RSDN вот в этой теме.

По сути, там были указаны реальные проблемы, которые есть при использовании fmtlib и, соответственно, std::format.

Одна из этих проблем в том, что для описания форматера для моего типа T мне нужно делать специализацию для fmt::formatter, а это нельзя сделать в моем пространстве имен. Поэтому, если я в своем пространстве имен только что определил тип T, то мне нельзя здесь же определить и фоматтер для него, нужно сперва закрыть свое пространство имен, а потом открыть его вновь.

Еще одна проблема показана вот в этом комментарии. Позволю себе процитировать:

Сейчас также все не сахар. Форматер в виде специализации класса не вызывается и всё, пока ты правильно не подберёшь синтаксис перегрузки. С шаблонными классами это бывает не очень просто. Вот пример у меня в коде:

namespace htlib::v2
{
template<typename type_t>
struct is_point {

    static std::false_type test(...);
    template<htlib::v2::uint_t dimensions, typename other_t>
    static std::true_type test(const htlib::v2::pointxd_t<dimensions, other_t>&);

    static constexpr bool value = decltype(test(std::declval<type_t>()))::value;
};
template<typename type_t>
inline constexpr bool is_point_v = is_point<type_t>::value;

// namespace htlib::v2

template<typename char_t, typename point_t>
class std::formatter<point_t, char_t, std::enable_if_t<htlib::v2::is_point_v<point_t>>>
{
//...
}

Вот такие мета-функции приходится писать что бы написать форматер для всех наследников базового шаблонного класса.

Хотя в случае с функциями была простая перегрузка, типа:

template<htlib::v2::uint_t dimensions, typename other_t>
void formatter(const htlib::v2::pointxd_t<dimensions, other_t>&);

В обсуждении прозвучала идея о том, что лучше бы было, если бы за парсинг и форматирование значений отвечали бы не классы, а свободные функции. Свободные функции могли бы размещаться в пространстве имен пользователя, соответственно, они бы подхватывались посредством ADL.

Очень хорошо выгоды от свободных функций сформулированы здесь:

если бы std::format для кастомизации использовал бы не шаблон класса со специализациями, а неквалифицированный вызов функции с каким-то предопределенным именем, это могло бы дать ряд преимуществ:

  • Пользователь мог бы определять кастомные форматтеры в том же пространстве имен, что и пользовательские типы. Это удобнее писать и удобнее читать, потому что не нужно рвать пространства имен или выносить определения в какие-то отдельные места;
  • При определении кастомных форматтеров пользователь мог бы использовать дополнительные параметры по умолчанию — как в списке шаблонных параметров, так и в списке формальных параметров функции, что дает возможность использования SFINAE и вообще дает большую гибкость в тех случаях, когда кастомизацию нужно сделать не для одного конкретного типа, а для какого-нибудь сеймейства типов, объединенных каким-то признаком;
  • Как частный случай — форматтер, определенный для базового класса автоматом будет работать и для всех производных, для которых не предоставлена своя собственая версия форматтера;
  • Используя квалифицированные вызовы, пользователь мог бы внутри кастомго форматтера повторно использовать форматтеры из других пространств имен, что дает возможность декорирования форматтеров.

Хотя лично мне перспектива писать свободные функции parse и format для своих типов не очень нравится, имхо, класс formatter с методами parse и format для таких целей удобнее, имхо. Да и совместимость с уже написанным кодом терять не хочется, так что подход со свободными функциями должен как-то сочетаться с уже написанными formatter-ами.

Посему возникла дурацкая идея о том, как можно подружить оба эти подхода.

Суть в том, чтобы оставить класс formatter как он есть. Но не создавать его напрямую, а получать посредством свободной функции-фабрики. Как раз эту самую функцию-фабрику можно будет определить в собственном пространстве имен рядом со своими типами.

Под катом слепленный на коленке за 10 минут пример того, как это может быть.

Насколько это все реально внедрить в fmtlib не знаю. Заглянул в исходники, но там не то, чтобы все сложно. Но это таки большой проект, в котором я ни бум-бум. Сходу не разобраться.

А копать глубоко нет возможности. Я тут, к сожалению, слегка зашился и чувствую, что едва хватает сил на выполнение обязательств по текущему проекту. Даже за PR для RESTinio не могу взяться :(

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

Напоследок скажу, что на RSDN-е были таки обозначены актуальные проблемы, с которыми люди сталкиваются в fmtlib и std::format. И было бы хорошо тем или иным способом решить эти проблемы. Наверняка способы найдутся.

понедельник, 24 октября 2022 г.

[prog] Ссылки на несколько критических по отношению к языку Go статей

Решил собрать в одно место ссылки на несколько статей, в которых рассказывается насколько в языке Go не все хорошо. В склерозник, что называется.

Первая статья: Data Race Patterns in Go. Специалисты из Uber-а приводят перечень проблем с многопоточностью, с которыми они столкнулись в своей кодовой базе. Общее впечатление от статьи: слишком уж много косяков в языке, который кичиться своей простой и удобной моделью конкурентного программирования.

Вторая статья: We Need To Talk About The Bad Sides of Go. На самом деле это один из постов в серии, где рассказывается о том, что в Go хорошо, что плохо и что хотелось бы исправить автору этой самой серии.

Третья, но даже не статья, а серия статей о недостатках языка Go. Приведу ссылку только на первую из серии, все остальные ссылки уже там, внутри. Итак, начинать следует отсюда: Go'ing Insane Part One: Endless Error Handling.


В общем-то, желания связываться с Go и так не было, а стало еще меньше :)

Заодно стал лучше понимать, почему некоторые люди говорят, что авторы Go застряли в 1980-х и пропустили все то, что успели придумать и опробовать в языкостроении за последние лет тридцать.

воскресенье, 23 октября 2022 г.

[life] Очередная веха в прослушивании плейлистов дня на Yandex.Music

Странная история (в плане того, что я сам не понимаю зачем она мне), о которой уже писал. Но есть повод вернуться к ней еще раз.

В сентябре 2022-го счетчик достиг значения 730, т.е. ровно два года ежедневного пользования плейлистами дня на Yandex.Music.

Тогда встал вопрос о том, а что дальше.

Дальше маячило красивое число 777.

Ну и вот, собственно.

Честно скажу, я сам понятия не имею зачем мне это все нужно.

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

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

Иногда мне кажется, что заставляя себя включить плейлист-дня на Yandex.Music хотя бы на пару минут я тем самым пытаюсь реабилитироваться за тогдашнюю неспособность ежедневного записывать температуру воздуха :)

Будет ли продолжение у этой странной истории?

А вот фиг знает. Хотелось бы, конечно, и до 888 довести. Но недавний негативный опыт с попыткой продления подписки на Yandex.Plus (раз, два, три) наводит на мысли, что в текущее турбулентное время подписки на сетевые сервисы не есть удобно и надежно. И прерваться все это может внезапно и не по твоей вине. Так что будем посмотреть.