Нашел в ленте LinkedIn замечательную мудрость-афоризм, которая в моем вольном переводе звучит так:
Программисты недооценивают все на свете, за исключением своих собственных возможностей.
Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
Нашел в ленте LinkedIn замечательную мудрость-афоризм, которая в моем вольном переводе звучит так:
Программисты недооценивают все на свете, за исключением своих собственных возможностей.
Сегодня ради спортивного интереса попробовал добить начатую вчера тему с созданием хитрого предиката для static_assert. Там нужно было сделать проверку для двух случаев. Для первого случая я сделал быстро, а про второй случай подумал, что он гораздо сложнее. Но, оказалось, что не так уж сложнее. Так что предикат получить удалось.
Но вот поведение компиляторов GCC и clang при его использовании меня удивило. С VC++ не проверял, не знаю как бы он себя повел бы.
Под катом большой кусок кода и короткий рассказ о том, как же вели себя компиляторы.
Выдалась возможность потратить некоторое время на очистку кода RESTinio от (полу)забытых FIXME. Один из них выглядит так:
template< typename 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. Тема получила неожиданное продолжение.