Наверное, насчет static_assert немного двусмысленно получилось в статье. Под «срабатыванием» подразумевалось именно прохождение ассерта, т.е. нормальная компиляция без ошибки. А ошибки не будет, если условие ассерта true, чего нам и надо. Иначе говоря, если код работает, и значения различаются, то все компилируется нормально. Я перефразировал в самой статье и обновил.
Да, здесь получается контекст, который не требует, чтобы writer <B> был complete type. Поэтому и использовался sizeof, для принудительного инстанцирования.
Но вообще это довольно интересный вопрос — почему бы не добавить зависимость от B в сам writer. Если сделать, как выше написали, (т.е. совсем убрать Tag из writer, а вместо него добавить B), то получится, что каждая из специализаций writer (для true и для false) попытается создать определение для flag, и нарушится one definition rule. То же самое произойдет, если оставить в writer оба параметра (Tag и B) — для каждого их набора будет попытка сгенерировать отдельное определение flag, и уже во время второй генерации все покрашится.
А dependent_writer все свои специализации (и для true == B, и для false == B) наследует от единственной специализации writer <int>, поэтому определение flag будет сгенерировано только однажды, и ODR не нарушится.
Тут просто имя пропущено. Оно ведь не нужно, параметр все равно нигде не используется. По сути это просто еще один шаблонный параметр со значением по умолчанию.
Вот тут, например, видно, что имя только опционально указывается в этом синтаксисе.
Нет, оно скроллится по пустому фону до слов «Вот так. Круг замкнулся...», и ничего так и не появляется. Потом вылетает при нажатии кнопки, а при новом запуске показывается уже экран с поступками, и дальше все работает хорошо (на первый взгляд). Информацию по версиям сейчас в личку брошу.
Вы сейчас пробудили во мне уже почти прошедшую БОЛЬ момента, когда я осознал, что экспорт в SVG делается у них транзитом через растровые форматы. Но что поделать, менять что-либо уже слишком поздно было, и пришлось танцевать с бубном. Зато теперь я знаю, что это плохой сервис.
Ну, я мыслю так: по полноте и удобству оно вряд ли может соперничать с cppreference или чем-то подобным. А вот чтобы распечатать и иметь возможность быстро пробежаться глазами — сгодится. Соответственно, забавность мне показалась желательным свойством, приятнее ведь повесить на стену что-то эдакое.
Из этого вытекает и довольно запутанная навигация, которая зато позволила сделать ее почти прямоугольной.
И да, вы правы насчет «модифицировать или создавать», я поправлю «или» на «либо» вечером.
Но вообще это довольно интересный вопрос — почему бы не добавить зависимость от B в сам writer. Если сделать, как выше написали, (т.е. совсем убрать Tag из writer, а вместо него добавить B), то получится, что каждая из специализаций writer (для true и для false) попытается создать определение для flag, и нарушится one definition rule. То же самое произойдет, если оставить в writer оба параметра (Tag и B) — для каждого их набора будет попытка сгенерировать отдельное определение flag, и уже во время второй генерации все покрашится.
А dependent_writer все свои специализации (и для true == B, и для false == B) наследует от единственной специализации writer <int>, поэтому определение flag будет сгенерировано только однажды, и ODR не нарушится.
Вот тут, например, видно, что имя только опционально указывается в этом синтаксисе.
А после нажатия «Изменить мир к лучшему» вообще вылетает, увы.
Но идея отличная и, судя по скриншотам, реализованная хорошо. Только бы баги пофиксить.
Из этого вытекает и довольно запутанная навигация, которая зато позволила сделать ее почти прямоугольной.
И да, вы правы насчет «модифицировать или создавать», я поправлю «или» на «либо» вечером.
www.gliffy.com/go/publish/8874265
www.gliffy.com/go/publish/8956331
Я, правда, не уверен, что они останутся доступными, когда у меня закончится триал.