ChatGPT для программиста

[beldmit]

Я понял, что бы я хотел вот от этого ChatGPT. Это, конечно, нифига не интеллект. Но это — хрень, которая работает без ошибок и не задалбывается от рутины.

В моём любимом OpenSSL типичная функция на 10 строчек содержательной работы содержит 10 строчек инициализации, 40 строчек проверок того, что инициализация и содержательная работа удались (функция вернула нужное значение) и ругань по этому поводу, и ещё 10 строк очистка тех ресурсов, которые я насоздавал. И форматирование, которое, впрочем, можно поручить редактору, осталось понять, как именно.

А хочу я написать эти 10 содержательных строчек, сказать "а теперь вставь все проверки и очистку как в соседних функциях" и получить на выходе код, обвешанный некоторой обвязкой. Можно ещё проверить на типовые ошибки типа buffer overflow. В общем, даже на первый взгляд производительность содержательно растёт в разы.

Comments

[elglin]

Окей, я пошел тупо в лоб.

- проверить аргументы
То есть у нас набор аргументов задает некоторый тип, к которому положена функция-валидатор. Я не готов утверждать, что это изоморфно классу с конструктором, но до отвращения похоже.
- породить из них какие-то локальные объекты, при неудаче выругаться (часто контекст-специфично), перейти по goto в конец, где за собой убирают
Задержанная инициализация, которая, если мы не кидаемся исключениями, возвращает код ошибки, который мы можем скормить специфичной для типа функции, чтобы получить смысл. Ах, да, и убрать за собой. Хм... пара методов и деструктор.
- сделать содержательные шаги, тоже проверив, что каждый из них удался, при ошибке перейти к освобождению
Если мы продолжаем оставаться в ООП-парадигме, то это, по сути, перегруженный для каждого подкласса абстрактный метод.
- присвоить содержательный результат возвращаемой переменной
Ну это не проблема в какой угодно парадигме
- освободить вот это вот всё (3-4-много объектов)
Деструктор!
- вернуть результат
Не проблема.

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

[beldmit]

Да, кое-что по сути деструкторы и конструкторы - но кидать исключения как-то не хочется по куче причин.

[elglin]

Тебя никто не заставляет. У тебя есть сколько-то штатных кодов возврата и одна функция (по сути, метод класса), которая преобразует код возврата в что-то удобочитаемое. А если хочется что-то более сложное, то мы приходим либо к исключениям, либо к голанг-стайл возврату, когда у тебя из функции приезжает пара (res, err).

[beldmit]

У меня есть коллега, сильно замороченный на side channels. Он измерял, и код с брошенным и перехваченным исключением от кода с ошибкой даёт очень чёткое отличие по времени исполнения.

[elglin]

Так я не предлагаю исключениями кидаться, я их сам не люблю.
Очень условно, у тебя сигнатура функции
int some_func(void* args, void* error);
Далее, у тебя есть функция
char* some_func_error_helper(int retcode, void* error);
которая по коду ошибки и дополнительной информации (которая запросто может быть NULL в большинстве случаев) выдает тебе удобочитаемое сообщение.

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