1. В С++ есть одна фича, которую очень сильно недооценивают, а очень зря. Это Attribute specifier sequence.
Фактически вы можете писать всякие атрибуты функциям, переменным и так далее.
Есть как и стандартные атрибуты по типу [[nodiscard]]/[[likely]], а наибольший интерес мне предоставляет user defined атрибуты. Вы можете даже свои рекламные интеграции ставить
Хорошо, есть у нас такие атрибуты, они были давно в MSVC компиляторе.
Самый сочный факт этого заключается в том, что это является одним из очень редких свойств кастомизации С++. Вы можете создавать свои атрибуты и компиляторы этим активно пользуются. https://clang.llvm.org/docs/AttributeReference.html
Что ещё можно сделать с ними? На самом деле пока никто не взялся за borrow checker в С++, ну, потому что это сложно, но в целом в моей голове использовать такие атрибуты для этого вполне реально как минимум для lifetime аннотаций
Абсолютно валидный С++, а дальше какой-нибудь clang уже сам проверяет эти аннотации на корректность передачи.
Почему это сложно? Ну, даже какой-то простой пример вроде
В итоге надо много чего переделать, скажем, парные итераторы в функциях должны уйти, стандартные библиотеки надо писать с такими атрибутами. Это вполне реально, и я не могу перестать думать об этой идее уже несколько дней.
Почитать немного другой подход для borrow checker в С++ можно от коллег из chromium.
2. Я решил исправить все баги, которые были переписаны с hyperscan в Vectorscan. TL;DR мне очень не понравилось, что вообще переписывали какие-то части без понимания, что оно делает. Но да, не протестировать address sanitizerом очень плохо. Да тут даже бы Rust не помог, три ошибки чисто логические. Зато разобрался в достаточно жёстких алгоритмах самого hyperscan.
https://github.com/VectorCamp/vectorscan/pull/93
Не знаю, что этим хочется сказать, наверное, то, что софт плохо написан, и не стоит переписывать вещи, и вы должны подумать несколько раз, если удаляете какой-то код. Я бы автору незачет поставил.
Переписал, всем проблем создал, а в итоге у нас теперь два репозитория с разными багами.
3.
Тут вышел FAST'22, опять сочные статьи про Intel Optane и LSM Trees и в целом про storage
https://www.usenix.org/conference/fast22/technical-sessions
Надо бы какую-нибудь статью почитать внимательно, а раз наш недельный марафон подходит к концу, надо бы успеть до завтра, а то я уже в кризисе, о чем писать!
Фактически вы можете писать всякие атрибуты функциям, переменным и так далее.
Есть как и стандартные атрибуты по типу [[nodiscard]]/[[likely]], а наибольший интерес мне предоставляет user defined атрибуты. Вы можете даже свои рекламные интеграции ставить
[[deprecated("subscribe to my Patreon")]] int foo();Хорошо, есть у нас такие атрибуты, они были давно в MSVC компиляторе.
Самый сочный факт этого заключается в том, что это является одним из очень редких свойств кастомизации С++. Вы можете создавать свои атрибуты и компиляторы этим активно пользуются. https://clang.llvm.org/docs/AttributeReference.html
Что ещё можно сделать с ними? На самом деле пока никто не взялся за borrow checker в С++, ну, потому что это сложно, но в целом в моей голове использовать такие атрибуты для этого вполне реально как минимум для lifetime аннотаций
int foo(const Type1& [[lifetime("'a")]], const Type2& [[lifetime("'a")]]);Абсолютно валидный С++, а дальше какой-нибудь clang уже сам проверяет эти аннотации на корректность передачи.
Почему это сложно? Ну, даже какой-то простой пример вроде
std::sort(cont.begin(), cont.end()) должен взять два итератора и с точки зрения модели Rust это не скомпилируется, так как мы передаем управление внутренним объектам сортировке. Если вместо std::sort другая функция, это может сломаться в теории.В итоге надо много чего переделать, скажем, парные итераторы в функциях должны уйти, стандартные библиотеки надо писать с такими атрибутами. Это вполне реально, и я не могу перестать думать об этой идее уже несколько дней.
Почитать немного другой подход для borrow checker в С++ можно от коллег из chromium.
2. Я решил исправить все баги, которые были переписаны с hyperscan в Vectorscan. TL;DR мне очень не понравилось, что вообще переписывали какие-то части без понимания, что оно делает. Но да, не протестировать address sanitizerом очень плохо. Да тут даже бы Rust не помог, три ошибки чисто логические. Зато разобрался в достаточно жёстких алгоритмах самого hyperscan.
https://github.com/VectorCamp/vectorscan/pull/93
Не знаю, что этим хочется сказать, наверное, то, что софт плохо написан, и не стоит переписывать вещи, и вы должны подумать несколько раз, если удаляете какой-то код. Я бы автору незачет поставил.
Переписал, всем проблем создал, а в итоге у нас теперь два репозитория с разными багами.
3.
Тут вышел FAST'22, опять сочные статьи про Intel Optane и LSM Trees и в целом про storage
https://www.usenix.org/conference/fast22/technical-sessions
Надо бы какую-нибудь статью почитать внимательно, а раз наш недельный марафон подходит к концу, надо бы успеть до завтра, а то я уже в кризисе, о чем писать!