четверг, 14 декабря 2023 г.

[prog.c++] Несколько не очень приятных открытий...

...ну или я просто пока не понял, как это можно "правильно приготовить" :(


Впервые довелось столкнуться с Google Test (далее gTest). Ранее пользовался либо чем-то самодельным, либо Catch2, либо Doctest. А вот теперь и до Google Test очередь дошла.

В принципе, мощная штука, но одна вещь оттуда сейчас чуть ли не show-stopper-ом выступила.

Дело в том, что там можно определить свой метод SetUpTestSuite для подготовки test-suite к исполнению. И мне в этом методе нужно загрузить некие данные, которые затем потребуются в test-cases, входящих в мой test-suite.

Но засада оказалась в том, что если в SetUpTestSuite возникает исключение (например, по какой-то причине я не смог загрузить нужные мне данные), то gTest все равно пытается выполнить входящие в test-suite test-cases. Хотя без нужных данных все эти test-cases завершаются негативно. А вот гарантировать отсутствие исключений я не могу -- иногда данные могут и не загружаться.

И я пока не понял, как поступать в этих случаях. Неужели просто дергать std::abort внутри SetUpTestSuite?


После долгих-долгих лет работы вне IDE потребовалось таки воспользоваться VisualStudio. Надеюсь, что это временно, однако пока нужно. Плеваться приходится много, но это тема отдельного разговора.

Вот что стало по-настоящему неприятным сюрпризом, так это то, что когда инициируешь запуск тестов из Test Explorer, то студия напрочь выбрасывает все, что печатается в stderr/stdout. Грубо говоря, есть у тебя в тесте какая-то тестовая печать в std::cout... И все, забудь! Что там было напечатано из Test Explorer не видно :(

Очень надеюсь, что это я неграмотный идиот и просто не знаю куда смотреть. Может там есть какая-то волшебная кнопка, чтобы показать stderr/stdout от тестов?


В C++20 добавили char8_t. Удобная штука, чтобы конструировать, например, std::filename::path не беспокоясь о том, как это будет воспринято. Например, под Windows такая запись:

std::filename::path my_path{u8"./Файл-С-Именем-На-Русском-Языке.你好.txt"};

теперь обрабатывается уже полностью корректно. А вот в рамках C++17, насколько я помню, будет облом в run-time.

Еще в C++20 добавили u8string_view. Это как string_view, но для char8_t.

Но, оказалось, что u8string_view в рамках C++20 нельзя передать в std::format. Цынк.

Ну и да, еще и диагностика как всегда в C++ ;)

Кстати говоря, как я понял, нельзя заставить std::format делать std::u8string. Можно либо std::string, либо std::wstring.


На правах саморекламы: изобретаю велосипеды для себя, могу изобретать и для вас.

среда, 13 декабря 2023 г.

[prog.json.question] Нужна ли такая фича в библиотеке (де)сериализации JSON?

Есть у нас маленькая обертка над RapidJSON под названием json_dto. Ничего выдающегося, просто попытка применить идею из Boost.Serialization для того, чтобы с RapidJSON-ом работать было удобно.

Давеча в json_dto прилетел pull request, добавляющий специфическую функциональность.

Грубо говоря, нужно (де)сериализовать элементы tuple, которые в JSON представляются массивом с элементами разных типов. Что-то вроде:

{"x": [1, "abc"]}

Где для ключа "x" значением будет tuple<int, string> содержащий (1, "abd").

Сам я с такими JSON в своей практике еще не сталкивался. Поэтому вынужден обратиться за помощью к читателям блога: доводилось ли вам видеть подобные JSON-ы? Если да, то является ли это нормальной (распространенной) практикой?

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

понедельник, 11 декабря 2023 г.

[prog.work.flame] Много слов на тему ролика АйТиБорода "ИИ убивает программирование, и вот как"

На прошлой неделе урывками посмотрел откровенно кликбейтный ролик "ИИ убивает программирование, и вот как" от известного в узких кругах АйТиБорода.

Урывками потому, что по мере просмотра подгорало знатно, тот самый случай, когда огнеупорная сидушка была бы кстати :)

Кратко первые впечатления по горячим следам изложил в соцсетях (VK, LinkedIn). Сейчас же попробую развернуть мысль.

Но сразу оговорюсь: я вообще не в курсе того, что уже умеет делать ИИ и что он сможет делать в ближайшем или отдаленном будущем. Понятия не имею насколько ИИ угрожает профессии программиста и даже не буду пытаться оценивать то, являются озвученные в ролике прогнозы алармисткими или, напротив, реалистичными (на мой взгляд это вообще больше похоже на замануху "подписывайтесь на мой подкаст про AI").

Моя цель -- сосредоточится на трех тезисах АйТиБороды, которые я выделил из его получасового выступления. И эти тезисы касаются профессии "программист", а не влияния на эту профессию такого фактора, как ИИ. Причем не вообще профессии "программист" в целом мире, а феномена профессии "программист" (как частного случая явления "айтишник") на обломках бывшего СССР, т.к. у нас здесь своя специфика. А это важно, поскольку тот же АйТиБорода, как по мне, есть яркий пример следствия этой самой специфики.

Букв будет много, кому интересно, милости прошу под кат. Но сразу предупреждаю, что все нижеизложенное -- это мое сугубо субъективное и, вероятно, маргинальное мнение подвинутого на велосипедостроении старпера.