Мы используем yandex-taxi-testsuite для подобных вещей. Это отдельный Python пакет, и он доступен в pip. Он умеет поднимать не только Postgres, но и Redis, Valkey, Mongo... а ещё умеет поднимать ваш сервис, патчить ваши конфиги, делать запросы в ваш сервис и много-много всего другого
Полноценно интегрировать своё приложение с yandex-taxi-testsuite может быть не просто. В качестве примера можно глянуть в userver/testsuite, там как раз лежит всё для бесшовной интеграции приложений на userver. Если нужен только подъем базы от yandex-taxi-testsuite, то всё попроще, и можно посмотеть на userver/postgres тесты в качестве примера
Мы сейчас во многих местах фреймворка используем Boost.PFR для рефлексии. Как раз пару дней назад был релиз Boost 1.91 и там я добавил экспериментальную поддержку C++26 рефлексии в PFR. Через пол годика можно снимать эксперимент и использовать по умолчанию
Но вот использовать рефлексию C++26 не под ifdef макросами мы не сможем ещё лет 6 - наши пользователи используют C++20
Пока в большинстве дистрибутивов нет нужных инструментов для надёжной работы с модулями. Нас это конечно не остановит :) Займёмся модуляризацией где-то через пол годика
simd будет в C++26. В GCC-16 уже будет готовая к использованию реализация, а до этого была в GCC реализация std::experimental::simd, на основе которой как раз и принимали std::simd
В C нет такого же понятия "объекта", как в C++. Соответственно в C можно спокойно написать в одно поле union, прочитать из другого, и это будут просто байтики. А в C++ стандарт оперирует объектами и их временами жизни. Это позволяет делать некоторые хитрые оптимизации (которые пока редко включают компиляторы по умолчанию, как раз из-за того что сломается C код)...
Вот и получается два противоречивых требования - хочется и совместимость с C, и хочется новые оптимизации. Балансирование между этими двумя желаниями приводит к решениям, на подобие common sequence initialization
Фундаментальное ограничение. Если возвращать не Input диапазон, то как раз вылезают все проблемы с тем, что можно несколько раз проходить по диапазону, значение может измениться после первой фильтрации и новая фильтрация приводит к непредсказуемым последствиям (UB)
Есть концепты, которым могут удовлетворять разные диапазоны. Так например для Input концепта требуется наличие двух операторов ++ и одного оператора *. Для Bidirectional концепта необходимо ещё и наличие операторов --.
`view` принимают диапазон на вход и выдают диапазон. `view` реализуют алгоритм, и некоторые алгоритмы требуют для своей эффективной реализации удовлетворения более требовательного концепта на вход. Так например std::views::reverse требуется Bidirectional диапазон, так как надо идти по диапазону в обратном порядке и нужено оператор--.
Так вот, filter возвращает Bidirectional диапазон, если ему на вход пришёл Bidirectional диапазон, за счёт чего скомпилируется идущий за ним std::views::reverse.
safe_filter всегда возвращает Input, с которым не может работать std::views::reverse так как у такого диапазона нет оператора --.
С точностью до наоборот - если InputRange - то можно только инкрементить и один раз разадрессовывать. А значит отваливаются все те ranges, которые требуют на вход Forward/Bidirectional
Почему нельзя смотреть на них и выбирать поведение, соответствующее версии стандарта
В случае перехода от filter к поведению safe_filter меняется тип диапазана с BidirectionalRange/ForwardRange на InputRange. Другими словами, некоторые валидные pipeline обработки просто перестают компилироваться. Как предлагаете обойти эту проблему, чтобы не сломать валидный пользовательский код?
Оба предложения обсуждались несколько раз. Пока оптимистично планируется их приземлить в C++29
Если вы заинтересованы в этих предложениях, то кажется самое простое что можно сделать - воспользоваться https://github.com/stdgraph на основе которого строятся данные нововведения в стандарт C++ и зарепортить авторам библиотеки фидбек
Вы просто не читаете аналогичные отчёты по другим языкам программирования ;-) А соответственно не знаете о проблемных местах других языков программирования и о том, какие пути обхода проблем используются там
о, спасибо большое, будем смотреть и разбираться
Разные энтузиасты пробовали доьавить поддержку Win, но на этапе сборки как правило застревали :(
Если хотите попробовать - присылайте PR, с радлстью поревьюим и вмержим
Мы используем yandex-taxi-testsuite для подобных вещей. Это отдельный Python пакет, и он доступен в pip. Он умеет поднимать не только Postgres, но и Redis, Valkey, Mongo... а ещё умеет поднимать ваш сервис, патчить ваши конфиги, делать запросы в ваш сервис и много-много всего другого
Полноценно интегрировать своё приложение с yandex-taxi-testsuite может быть не просто. В качестве примера можно глянуть в userver/testsuite, там как раз лежит всё для бесшовной интеграции приложений на userver. Если нужен только подъем базы от yandex-taxi-testsuite, то всё попроще, и можно посмотеть на userver/postgres тесты в качестве примера
Мы сейчас во многих местах фреймворка используем Boost.PFR для рефлексии. Как раз пару дней назад был релиз Boost 1.91 и там я добавил экспериментальную поддержку C++26 рефлексии в PFR. Через пол годика можно снимать эксперимент и использовать по умолчанию
Но вот использовать рефлексию C++26 не под ifdef макросами мы не сможем ещё лет 6 - наши пользователи используют C++20
Пока в большинстве дистрибутивов нет нужных инструментов для надёжной работы с модулями. Нас это конечно не остановит :) Займёмся модуляризацией где-то через пол годика
Мы когда-то проверяли на одной из BSD, и даже апстримили патчи в смежные проекты (кажется gRPC), чтобы сборка работала
Но без настроенного CI и энтузиаста, желающего поддержать платформу, скорее всего сборка немного сломалась.
Кстати, мы ищем добровольцев https://userver.tech/d1/d00/md_en_2userver_2distro__maintainers.html. Не хотите им стать?
simdбудет в C++26. В GCC-16 уже будет готовая к использованию реализация, а до этого была в GCC реализацияstd::experimental::simd, на основе которой как раз и принималиstd::simdВ C нет такого же понятия "объекта", как в C++. Соответственно в C можно спокойно написать в одно поле union, прочитать из другого, и это будут просто байтики. А в C++ стандарт оперирует объектами и их временами жизни. Это позволяет делать некоторые хитрые оптимизации (которые пока редко включают компиляторы по умолчанию, как раз из-за того что сломается C код)...
Вот и получается два противоречивых требования - хочется и совместимость с C, и хочется новые оптимизации. Балансирование между этими двумя желаниями приводит к решениям, на подобие common sequence initialization
Сборщик мусора? :)
Фундаментальное ограничение. Если возвращать не
Inputдиапазон, то как раз вылезают все проблемы с тем, что можно несколько раз проходить по диапазону, значение может измениться после первой фильтрации и новая фильтрация приводит к непредсказуемым последствиям (UB)Есть концепты, которым могут удовлетворять разные диапазоны. Так например для
Inputконцепта требуется наличие двух операторов ++ и одного оператора *. ДляBidirectionalконцепта необходимо ещё и наличие операторов --.`view` принимают диапазон на вход и выдают диапазон. `view` реализуют алгоритм, и некоторые алгоритмы требуют для своей эффективной реализации удовлетворения более требовательного концепта на вход. Так например
std::views::reverseтребуетсяBidirectionalдиапазон, так как надо идти по диапазону в обратном порядке и нужено оператор--.Так вот,
filterвозвращаетBidirectionalдиапазон, если ему на вход пришёлBidirectionalдиапазон, за счёт чего скомпилируется идущий за нимstd::views::reverse.safe_filterвсегда возвращаетInput, с которым не может работатьstd::views::reverseтак как у такого диапазона нет оператора --.Спасибо большое, поправил
P.S.: хабр рекомендует об опечатках сообщать напрямую в личку автору
А что по вашему мнению помогло бы исправить ситуацию? Какие дополнения к стандарту?
С точностью до наоборот - если InputRange - то можно только инкрементить и один раз разадрессовывать. А значит отваливаются все те ranges, которые требуют на вход Forward/Bidirectional
В случае перехода от filter к поведению safe_filter меняется тип диапазана с BidirectionalRange/ForwardRange на InputRange. Другими словами, некоторые валидные pipeline обработки просто перестают компилироваться. Как предлагаете обойти эту проблему, чтобы не сломать валидный пользовательский код?
Оба предложения обсуждались несколько раз. Пока оптимистично планируется их приземлить в C++29
Если вы заинтересованы в этих предложениях, то кажется самое простое что можно сделать - воспользоваться https://github.com/stdgraph на основе которого строятся данные нововведения в стандарт C++ и зарепортить авторам библиотеки фидбек
В этот раз с поддержкой всё уже очень не плохо. GCC-16 поддерживает как рефлексию, так и контракты. Clang тоже с рефлексией неплохо справляется
Думаю C++26 очень оперативно поддержат (в этом стандарте нет C++20-модуле-подобных новинок, затрагивающих системы сборки, тулчейны и вообще всё)
filterуже 6 лет с нами, аж с C++20А дальше тонкий вопрос - хотите ли сломать ~20% использований чтобы обнаружить 0.1%-1% UB? Комитет выбрал так не делать и идти по пути
safe_filterBoost.Asio уже работает с executors. Так что ответ "да" на оба вопроса
Вы просто не читаете аналогичные отчёты по другим языкам программирования ;-) А соответственно не знаете о проблемных местах других языков программирования и о том, какие пути обхода проблем используются там