Посмотрел пару примеров игр, заметил что в хедерах с рефлексией мета описания в среднем занимают около половины содержания класса, притом внутри себя почти полностью дублируют информацию, которую можно вытащить из информации об исходном коде (вплоть до defaultValue)
Вопрос, рассматривались ли альтернативные пути рефлексии, например на базе плагина к компилятору как у какого-нибудь https://github.com/chocolacula/easy_reflection_cpp, или с учётом нового стандарта, на базе рефлексии c++26?
(Еще накину на поглядеть свою избушку на курьих ножках https://github.com/simplepersonru/rgen)
Представим себе такую работу, которая взаимодействует с эмоциями других людей. Кинематограф, авторство книг/статей, политика и многое другое, явно или неявно.
Кто способен лучше вызывать эмоции у других людей?
Человек, профессионал в своей области. Понимает что такое эмоции, как с призмы профессиональных знаний(обьективнее), так и собственного человеческого опыта (субъективнее, ограничено опытом одной человеческой жизни).
AI, профессионал по всему одновременно. Прочитал и пережевал через себя любые возможные материалы в мире про эмоции, но не имел возможности их "прожить"
а если попробовать собрать комбайн из множества бесплатных/ограниченных API (например qwen дает сколько-то бесплатных), возможно локально что-то худо-бедно (какого размера модель используете?). И сделать сервер-шлюз-распределитель, кто будет звать одну из кучи этих вариантов по приоритетам и на ошибки пробовать другие варианты :)
Есть ли у вас интеграционные авто-тесты, которые внутри себя поднимают какой-нибудь in-memory postgresql, который целиком со всем своим клиент-сервером живет в RAM во время исполнения бинаря теста?
Иногда искал что-то готовое, находил только подобные упоминания для node-js инфраструктуры
Смотря какой процент бытовой физической активности был заложен в хождение по магазинам.
Если человек 24/7 сидит за компом на удалёнке и на улицу выбирался только в магазин, то это усугубит проблемы со здоровьем, которые теоретически тоже можно подбить к экономике и экономической выгоде)
Наверное в этом контексте был бы интересен инструмент, который позволяет работать с картинками, как с первоисточником (может и с некоторым подобием переменных, как показывает автор), при этом имел бы достаточно минималистичный текстовый дамп, чтобы можно было, например, анализировать диффы кода, при просмотре изменений в коммите
Вы прекрасно показали, как 11 санитайзеров дают 10 разных результатов. Это — идеальная иллюстрация принципа "не доверяй, а проверяй" при выборе инструментов безопасности.
Да, но откуда он его скачает? Где мы разместим и будем хранить эти бинарные зависимости. У пакетных менеджеров есть свои registry, которые можно поднять. Если менеджить бинарные зависимости просто в гит репозитории, у этого есть свои существенные недостатки
Наверняка можно организовать это через условые releases из условного github, но эту логику со скачиванием определенной версии релиза и тд, ее нужно реализовывать руками. Если вам известно о другом существующем способе через cmake заниматься менеджментом бинарных зависимостей, поделитесь пожалуйста
Как цмэйком управлять бинарными зависимостями, их кэшированием, версиями и тд? Скачивать это хорошо, но ведь множество библиотек мы подключаем уже собранными, в т.ч. локальные внутри проекта, как этим всем управлять?
Я не понял для чего мне dev контейнеры в этой задаче. Делая свой Dockerfile я имею полный контроль над этим образом, его содержимым, конфиг файлах и тд. Местами иногда приходилось "хакать" - например ставить сурс-листы для пакетов из более высоких версий дистрибутива linux и докачивать только определенные пакеты определенных версий. dev контейнер описывается декларативно через жисон и как будто в этом всем меньше контроля над происходящим.
Посмотрел пару примеров игр, заметил что в хедерах с рефлексией мета описания в среднем занимают около половины содержания класса, притом внутри себя почти полностью дублируют информацию, которую можно вытащить из информации об исходном коде (вплоть до defaultValue)
Вопрос, рассматривались ли альтернативные пути рефлексии, например на базе плагина к компилятору как у какого-нибудь https://github.com/chocolacula/easy_reflection_cpp, или с учётом нового стандарта, на базе рефлексии c++26?
(Еще накину на поглядеть свою избушку на курьих ножках https://github.com/simplepersonru/rgen)
Представим себе такую работу, которая взаимодействует с эмоциями других людей. Кинематограф, авторство книг/статей, политика и многое другое, явно или неявно.
Кто способен лучше вызывать эмоции у других людей?
Человек, профессионал в своей области. Понимает что такое эмоции, как с призмы профессиональных знаний(обьективнее), так и собственного человеческого опыта (субъективнее, ограничено опытом одной человеческой жизни).
AI, профессионал по всему одновременно. Прочитал и пережевал через себя любые возможные материалы в мире про эмоции, но не имел возможности их "прожить"
Ставлю на человека, а вы?
для такого человечество придумало matrix + element
https://cppconf.ru/talks/20010047-cyberpunk-c-77-applying-fast-and-simple-reflection-with-specific-examples-and-scenarios/
не на стандартной конечно рефлексии, но есть это и многое другое, недавно рассказывал на cppconf, там презентация приложена и в конце ссылочка на проект
https://github.com/simplepersonru/rgen
Скорее всего есть бинарники, положенные в репу
а если попробовать собрать комбайн из множества бесплатных/ограниченных API (например qwen дает сколько-то бесплатных), возможно локально что-то худо-бедно (какого размера модель используете?). И сделать сервер-шлюз-распределитель, кто будет звать одну из кучи этих вариантов по приоритетам и на ошибки пробовать другие варианты :)
Вероятно зависит от версии Qt
Немножко может не по теме, но
Есть ли у вас интеграционные авто-тесты, которые внутри себя поднимают какой-нибудь in-memory postgresql, который целиком со всем своим клиент-сервером живет в RAM во время исполнения бинаря теста?
Иногда искал что-то готовое, находил только подобные упоминания для node-js инфраструктуры
а в рефлексию по итогу без изменений зашли пользовательские аттрибуты? Где-то раньше видел прототипы кода.
2. Конкретно здесь, в случае когда строки "a", "б" и в комбинации с кириллицей правильнее было бы выводить:
"a" + "б" == "а и б сидели на трубе"
Привет! как же так. вот ссылка https://github.com/simplepersonru/SimpleOntoDoc, точно такая же как в статье. Репозиторий публичный
Смотря какой процент бытовой физической активности был заложен в хождение по магазинам.
Если человек 24/7 сидит за компом на удалёнке и на улицу выбирался только в магазин, то это усугубит проблемы со здоровьем, которые теоретически тоже можно подбить к экономике и экономической выгоде)
Наверное в этом контексте был бы интересен инструмент, который позволяет работать с картинками, как с первоисточником (может и с некоторым подобием переменных, как показывает автор), при этом имел бы достаточно минималистичный текстовый дамп, чтобы можно было, например, анализировать диффы кода, при просмотре изменений в коммите
Ждем новостей "Представлен релиз коммита ..." :)
засквозило нейрослопом
Представим такой код:
Есть ли смысл в частичном преобразовании в ANY? т.е. примерно вот так: (все что можно, суем в ANY, остальное оставляем как было)
p.s. я не силен в особенностях внутреннего устройства postgresql
> сколько хауса
p.s. хаоса, но мой комент только ради спойлера
Да, но откуда он его скачает? Где мы разместим и будем хранить эти бинарные зависимости. У пакетных менеджеров есть свои registry, которые можно поднять. Если менеджить бинарные зависимости просто в гит репозитории, у этого есть свои существенные недостатки
Наверняка можно организовать это через условые releases из условного github, но эту логику со скачиванием определенной версии релиза и тд, ее нужно реализовывать руками. Если вам известно о другом существующем способе через cmake заниматься менеджментом бинарных зависимостей, поделитесь пожалуйста
Как цмэйком управлять бинарными зависимостями, их кэшированием, версиями и тд? Скачивать это хорошо, но ведь множество библиотек мы подключаем уже собранными, в т.ч. локальные внутри проекта, как этим всем управлять?
Я не понял для чего мне dev контейнеры в этой задаче. Делая свой Dockerfile я имею полный контроль над этим образом, его содержимым, конфиг файлах и тд. Местами иногда приходилось "хакать" - например ставить сурс-листы для пакетов из более высоких версий дистрибутива linux и докачивать только определенные пакеты определенных версий. dev контейнер описывается декларативно через жисон и как будто в этом всем меньше контроля над происходящим.
А какие преимущества?