суббота, 13 августа 2022 г.

[prog.wow] Это высказывание достойно быть отлитым в граните

Нашел в ленте LinkedIn замечательную мудрость-афоризм, которая в моем вольном переводе звучит так:

Программисты недооценивают все на свете, за исключением своих собственных возможностей.

цынк

четверг, 11 августа 2022 г.

[prog.c++] Внезапное продолжение вчерашней темы и неожиданное для меня поведение компиляторов GCC и clang

Сегодня ради спортивного интереса попробовал добить начатую вчера тему с созданием хитрого предиката для static_assert. Там нужно было сделать проверку для двух случаев. Для первого случая я сделал быстро, а про второй случай подумал, что он гораздо сложнее. Но, оказалось, что не так уж сложнее. Так что предикат получить удалось.

Но вот поведение компиляторов GCC и clang при его использовании меня удивило. С VC++ не проверял, не знаю как бы он себя повел бы.

Под катом большой кусок кода и короткий рассказ о том, как же вели себя компиляторы.

среда, 10 августа 2022 г.

[prog.c++.humour] Как можно сделать хуже в попытке сделать лучше

Выдалась возможность потратить некоторое время на очистку кода RESTinio от (полу)забытых FIXME. Один из них выглядит так:

templatetypename Extra_Data, typename Producer, typename Handler >
class actual_router_entry_t : public router_entry_t< Extra_Data >
{
   //FIXME: compatibility between Extra_Data and Handler should be
   //checked by static_assert. If it's possible.

Суть здесь в том, что когда пользователь задает обработчик входящего запроса (тип Handler), то должна быть возможность передать в этот обработчик ссылку на generic_request_handle_t<Extra_Data>. А если это не так, например, если пользователь забыл про свой Extra_Data и подсовывает обработчик для простого request_handle_t, то будет ошибка компиляции.

Ошибки компиляции в шаблонном C++ном коде не самое приятное чтиво и разбираться с ними то еще удовольствие. Поэтому хотелось поставить в код какой-то static_assert, который бы явно говорил программисту: у тебя Handler не дружит с твоим же собственным Extra_Data.

Однако сходу написать такой static_assert в свое время не получилось, поэтому в коде был оставлен FIXME: мол, когда-нибудь руки дойдут.

Вот, руки дошли. Попробовал написать такой static_assert.

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

Написал, удовлетворил компилятор, попытался проверить как этот новый static_assert себя поведет.

Под катом два лога с сообщениями об ошибках компилятора GCC 9.4 в режиме C++14. Первый -- это старая версия с FIXME и без static_assert-а. Вторая -- новая версия без FIXME и со static_assert-ом.

Лично мне кажется, что разобраться с ошибкой в старой версии проще. Потому что благодаря static_assert-у на несчастного пользователя вываливается намного больше совершенно ненужной информации, разобраться в которой, на мой взгляд, гораздо сложнее.

Ну и да, видимо, этот FIXME из кода просто удалю и не буду делать никаких static_assert-ов. Потому что сложность кода растет, а пользы от этого никакой :(

Upd. Тема получила неожиданное продолжение.