пятница, 31 марта 2023 г.

[prog.flame.humour] Мы на пути к такому понятию, как hand-made software?

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

Может мы уже движемся к тому, что со временем львиная доля софта будет написана ИИ. И только изредка где-то, под спецзаказ и за совсем другие деньги, программное обеспечение будет писаться вручную, по старинке. Эдакий hand-made software, который могут себе позволить только состоятельные заказчики. Которые либо понимают, зачем им это нужно, либо же просто так понтуются.


ЗЫ. Я понятия не имею к чему приведет развитие ИИ и какое влияние этот самый ИИ окажет на софтостроение. Может быть ИИ оставит меня без работы уже совсем скоро (чего не хотелось бы, т.к. пока даже не могу представить на что можно было бы переучиться). Но пока же это еще не произошло, так чего же расстраиваться раньше времени? ;)

понедельник, 27 марта 2023 г.

[prog.c++] Подсмотрел интересный трюк в докладе Ивана Чукича

Доклад "the expected outcome" с Meeting C++ 2022. Где-то на 10-й минуте докладчик демонстрирует простой шаблон класса для работы с кодами ошибок из API на чистом Си.

Наверняка этот подход уже давнишний баян, но я увидел его впервые, так что утащу к себе в склерозник.

Вкратце этот простой шаблон выглядит так:

template<typename T, typename ValidationPolicy>
class Result {
private:
   T value_;

public:
   bool has_value() const;
   T value() const;
   T error() const;
};

Т.е., мы храним значение, возвращенное какой-то C-шной функций (например, функцией open из POSIX), и посредством ValidationPolicy можем проверить, указывает ли это значение на ошибку или же на нормальный результат.

Для разных типов представления ошибок можно реализовать свои ValidationPolicy. Например, NonZeroAsError для случая, когда ноль означает успешное завершение, а ненулевое значение -- код ошибки. Или MinusOneAsError для случая, когда значение -1 указывает на ошибку, а остальные значения -- это успешный результат. И т.д.

В общем, как по мне, интересный подход для случая, когда нужно много иметь дело с API на чистом C, а исключения по тем или иным причинам применять нельзя.

PS. Реализации этого шаблона и в докладе не было, но, думается мне, проблем написать такую реализацию ни у кого не должно быть. Но если кому-то интересно, то дайте знать, набросаю (тут можно несколько вариантов придумать, для разных целей и условий).