У вас очень классный проект. Похож на boost::pfr. Позволю себе замечание, что &Rect::top_left не дает указатель, это не статический член класса, поэтому компилятор отдаст смещение о чем и был комметарий выше. Именно поэтому вы потом делаете owner.*member_ptr, вам нужен owner, а знать его на этапе компиляции невозможно поэтому часть функций помеченных constexpr все равно будет работать в рантайме, они вызываются из обычных функций, у них нет указателя на owner(его еще нет в памяти), и они не могут вычислить указатель на поле.
Большое спасибо что вспомнили про pfr! @antoshkka сделал огромную и очень крутую работу, но у такого подхода довольно много ограничений, которые я хотел обойти. Например у меня есть поддержка алиасов, можно анализировать все что угодно, в том числе печатать в консоль для дебага const и static. Вначале я хотел воспользоваться pfr, но в последствии отказался от него.
Ваше мнение - Объект один и тот же, а данные отличаются. Мое мнение другое - разным данным разные объекты и наоборот, иначе это не сериализация. Это натягивание данных одного объекта, на другой. Тут естественно только руками.
А как вы хотите сериализовать? Как поток байт? Не вижу проблем, все будет скопировано бит в бит и обратно. Как строка? Поддержки таких значений у меня нет, но не забывайте это опенсорс проект одного человека. Если сделаете пулл реквест с их поддержкой я обещаю, сто вмерджу его первым.
Кроме того. Вы уверены, что сериализовать числа с плавающей точкой в json т.е. как строку это хорошая идея?
Сейчас 2022, рефлексия появится в 26, не уж то мне страдать еще 4 года?
Можно примерно предполагать только о том, что войдет в следующий стандарт(С++23) и то не факт, это все еще черновик.
На С++26 даже черновика нет, то о чем говорите вы, к сожалению, всего лишь PROPOSAL и нет никаких гарантий, что оно войдет в С++26. Есть гарантия, что оно НЕ войдет в С++23.
Не факт что новый стандарт будет в 26, увы.
Даже после утверждения стандарта, в компиляторах это появится не сразу.
Даже после появления в компиляторах как скоро production код будет портирован на С++26?
Я же вам предлагаю готовое, быстрое решение уже сейчас. Нужен С++17, который +/- довольно широко распространен. Если воспользоваться С++20 и растыкать по проекту constexpr, то часть логики уйдет в compile time.
У меня тоже периодически пригорает) Смысл этой части в том что есть и плюсы и минусы одновременно, в этом и заключается противоречивость. Я их не оценивал количественно или качественно. Если очень хочется примеров из блокчейна Bitcoin подойдет?
Если это легаси и нет возможности исправить формат данных, например, embeded без возможности обновления прошивки, то да... Выбора нет, придется разбирать руками. Но тем не менее это просчет в проектировании. С этим придется жить, но это неправильно.
Да ну бросьте) Все же гораздо проще. Если нужна поддержка двух разных версий: запиливаем TempHumDataV1 и TempHumDataV2. И обрабатываем их отдельно, достаем из разных таблиц, получаем через разные REST API. Если хочется извращений и стрельбы по ногам, то бросаем в конец данных признак версии - один байт с числом. Если он есть - v2(v3, etc.) Если там '}' - v1. Но повторю свою мысль. Это не очевидно, а значит признак плохого проектирования. Разные данные должны обрабатываться отдельно. Проектируете новый датчик, посылающий другие данные? Пусть он делает PUT https://api/v2/temp_hum.
На самом деле это уже немного другого толка задача. Решать ее придется в любом случае. Не важно как работать с данными, важно что это уже другие данные. В случае использования DOM поменяется имя/тип/путь к полю и код так же придется переписывать. Чтобы из-за этого не сесть в лужу нужны тесты. Ну и за версией API хотя бы минимально следить.
В С++ нет либ без таких недостатков. Это ограничение языка. Нет способа получить информацию о классе и присвоить значение его полям. Вся статья о том как это ограничение языка обойти.
Использование vcpkg как сабмодуль это рекомендованный способ установки. Пруф. Это снимает проблему кривой версионности. Когда из vcpkg одному проекту нужен curl одной версии, а второму другой.
Соглашусь с тем, что адрес и время компиляции несовместимы. В моем проекте можно перенести много логики из статической инициализации во время компиляции. Нужно только использовать C++20 constexpr std::vector. Но 17 стандарт не во всех проектах используется, что уж говорить о 20.
Рынок труда, это прежде всего рынок. Kubernetes в резюме появляется потому что у работодателей есть спрос на него. Это один из критериев по которым будут оценивать на собеседовании. Так что не очень красиво кидать такой камень в огород соискателей.
У вас очень классный проект. Похож на boost::pfr. Позволю себе замечание, что
&Rect::top_leftне дает указатель, это не статический член класса, поэтому компилятор отдаст смещение о чем и был комметарий выше. Именно поэтому вы потом делаетеowner.*member_ptr, вам нуженowner, а знать его на этапе компиляции невозможно поэтому часть функций помеченныхconstexprвсе равно будет работать в рантайме, они вызываются из обычных функций, у них нет указателя наowner(его еще нет в памяти), и они не могут вычислить указатель на поле.Как раз потому что из коробки их негде взять. Все же должен заметить, что наши с вами проекты очень разные и не совсем корректно их сравнивать.
Большое спасибо что вспомнили про pfr! @antoshkka сделал огромную и очень крутую работу, но у такого подхода довольно много ограничений, которые я хотел обойти. Например у меня есть поддержка алиасов, можно анализировать все что угодно, в том числе печатать в консоль для дебага
constиstatic. Вначале я хотел воспользоваться pfr, но в последствии отказался от него.Ваше мнение - Объект один и тот же, а данные отличаются. Мое мнение другое - разным данным разные объекты и наоборот, иначе это не сериализация. Это натягивание данных одного объекта, на другой. Тут естественно только руками.
А как вы хотите сериализовать? Как поток байт? Не вижу проблем, все будет скопировано бит в бит и обратно. Как строка? Поддержки таких значений у меня нет, но не забывайте это опенсорс проект одного человека. Если сделаете пулл реквест с их поддержкой я обещаю, сто вмерджу его первым.
Кроме того. Вы уверены, что сериализовать числа с плавающей точкой в json т.е. как строку это хорошая идея?
Вы описываете проблему:
обновили ПО и конфиг -> забаговано, надо откатывать -> откатываете только ПО оставив конфиг.
Верно? Это звучит не как проблема сериализации/десериализации, а как проблема с развертыванием.
У меня на этот счет несколько важных мыслей:
Сейчас 2022, рефлексия появится в 26, не уж то мне страдать еще 4 года?
Можно примерно предполагать только о том, что войдет в следующий стандарт(С++23) и то не факт, это все еще черновик.
На С++26 даже черновика нет, то о чем говорите вы, к сожалению, всего лишь PROPOSAL и нет никаких гарантий, что оно войдет в С++26. Есть гарантия, что оно НЕ войдет в С++23.
Не факт что новый стандарт будет в 26, увы.
Даже после утверждения стандарта, в компиляторах это появится не сразу.
Даже после появления в компиляторах как скоро production код будет портирован на С++26?
Я же вам предлагаю готовое, быстрое решение уже сейчас. Нужен С++17, который +/- довольно широко распространен. Если воспользоваться С++20 и растыкать по проекту constexpr, то часть логики уйдет в compile time.
Повторюсь. Вот прямо сейчас.
Не вижу ничего похожего в будущем стандарте.
У меня тоже периодически пригорает) Смысл этой части в том что есть и плюсы и минусы одновременно, в этом и заключается противоречивость. Я их не оценивал количественно или качественно. Если очень хочется примеров из блокчейна Bitcoin подойдет?
Хотелось бы увидеть опровержение доказывающее желтизну моих аргументов. Например ссылки на либы без таких недостатков.
Если это легаси и нет возможности исправить формат данных, например, embeded без возможности обновления прошивки, то да... Выбора нет, придется разбирать руками. Но тем не менее это просчет в проектировании. С этим придется жить, но это неправильно.
Да ну бросьте) Все же гораздо проще. Если нужна поддержка двух разных версий: запиливаем TempHumDataV1 и TempHumDataV2. И обрабатываем их отдельно, достаем из разных таблиц, получаем через разные REST API. Если хочется извращений и стрельбы по ногам, то бросаем в конец данных признак версии - один байт с числом. Если он есть - v2(v3, etc.) Если там '}' - v1. Но повторю свою мысль. Это не очевидно, а значит признак плохого проектирования. Разные данные должны обрабатываться отдельно. Проектируете новый датчик, посылающий другие данные? Пусть он делает PUT https://api/v2/temp_hum.
На самом деле это уже немного другого толка задача. Решать ее придется в любом случае. Не важно как работать с данными, важно что это уже другие данные. В случае использования DOM поменяется имя/тип/путь к полю и код так же придется переписывать. Чтобы из-за этого не сесть в лужу нужны тесты. Ну и за версией API хотя бы минимально следить.
В С++ нет либ без таких недостатков. Это ограничение языка. Нет способа получить информацию о классе и присвоить значение его полям. Вся статья о том как это ограничение языка обойти.
Использование vcpkg как сабмодуль это рекомендованный способ установки. Пруф. Это снимает проблему кривой версионности. Когда из vcpkg одному проекту нужен curl одной версии, а второму другой.
Соглашусь с тем, что адрес и время компиляции несовместимы. В моем проекте можно перенести много логики из статической инициализации во время компиляции. Нужно только использовать C++20 constexpr std::vector. Но 17 стандарт не во всех проектах используется, что уж говорить о 20.
Рынок труда, это прежде всего рынок. Kubernetes в резюме появляется потому что у работодателей есть спрос на него. Это один из критериев по которым будут оценивать на собеседовании. Так что не очень красиво кидать такой камень в огород соискателей.