yas::make_object<>() — шаблонная функция, в качестве параметров принимает набор пар, где first — хеш ключа, а second — порядковый номер. этот набор пар сортируется в компайлтайм при помощи yas::detail::mergesort(ссылка в коде). сортировка нужна чтоб в компайлтайм инициализировать мапу, которая используется для сопоставления ключей значениям в json. yas::make_object<>() возвращает тип yas::object<> — https://github.com/niXman/yas/blob/master/include/yas/object.hpp#L112
вобщем, хочется как-то избавиться от макроса и при этом получить какой-то человеческий синтаксис, что-то типа:
Здравствуйте, niXman, Вы писали:
X>вам нравится обувь зеленого цвета? закрытого типа. димесезонная.
Несомненно. Те что выслали вы на прошлой неделе мы давно уже съели.
Но вы боретесь с тривиальными вещами изощрёнными средствами.
А если ваши данные понадобиться читать не из с++?
Что мешает по описанию данных генерировать все нужные обёртки и заодно документацию?
Для чего умножать сложность и насиловать компилятор закатывая всё в монолит если можно разбить на не зависимые простые части?
template<typename KVI, std::size_t N, typename... Pairs>
constexpr object<KVI, Pairs...> // разве здесь вместо прост "Pairs..." нельзя записать более сложное выражение? Такое, чтобы по параметрам всё выводилось?
make_object(const char (&key)[N], Pairs &&... pairs) {
return {key, N-1, std::forward<Pairs>(pairs)...};
}
X>вобщем, хочется как-то избавиться от макроса и при этом получить какой-то человеческий синтаксис, что-то типа: X>
Здравствуйте, kov_serg, Вы писали:
_>А если ваши данные понадобиться читать не из с++?
читали/читаем из python и js.
_>Что мешает по описанию данных генерировать все нужные обёртки и заодно документацию?
поясните.
_>Для чего умножать сложность и насиловать компилятор закатывая всё в монолит если можно разбить на не зависимые простые части?
для того чтоб оставаться самым быстрым(ну почти, но скоро таки самым) сериализатором.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, B0FEE664, Вы писали:
BFE>разве здесь вместо прост "Pairs..." нельзя записать более сложное выражение? Такое, чтобы по параметрам всё выводилось?
ну... наверное можно, ну нужно понять, что?
BFE>Мне кажется, что make_object надо оставить и стремится надо к чему-то такому:
тут, насколько я могу сказать без компилятора, проблема в том, что у пар second-тип разный...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, kov_serg, Вы писали:
_>>А если ваши данные понадобиться читать не из с++? X>читали/читаем из python и js.
_>>Что мешает по описанию данных генерировать все нужные обёртки и заодно документацию? X>поясните.
Чем подход protobuf, flatbuffers хуже ?
_>>Для чего умножать сложность и насиловать компилятор закатывая всё в монолит если можно разбить на не зависимые простые части? X>для того чтоб оставаться самым быстрым(ну почти, но скоро таки самым) сериализатором.
Быстрее чем flatbuffers ?
Здравствуйте, _NN_, Вы писали:
_NN>Чем подход protobuf, flatbuffers хуже ?
о чем вы все говорите?
как protobuf и flatbuffers соприкасаются с этой темой?
_NN>Быстрее чем flatbuffers ?
в разы.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, _NN_, Вы писали:
_NN>>Чем подход protobuf, flatbuffers хуже ? X>о чем вы все говорите? X>как protobuf и flatbuffers соприкасаются с этой темой?
Насколько я понял kov_serg , то вопрос там состоял в том, почему не сделать генератор кода вместо насилования плюсов.
Тогда можно и получить простое описание и максимально возможную скорость работы без шаблонных усложнений.
Здравствуйте, _NN_, Вы писали:
_NN>Насколько я понял kov_serg , то вопрос там состоял в том, почему не сделать генератор кода вместо насилования плюсов.
так это как-то через попу получится... дополнительный pre build step + post build step, и, к тому же, не получится in-place.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, _NN_, Вы писали:
_NN>>Насколько я понял kov_serg , то вопрос там состоял в том, почему не сделать генератор кода вместо насилования плюсов.
X>так это как-то через попу получится... дополнительный pre build step + post build step, и, к тому же, не получится in-place.
Зачем пост ?
Только перед сборкой нужно сгенерировать код.
Понятно, что лучше иметь нормальную систему макросов и просто встроить генерацию кода в процесс компиляции, но этого нет и похоже не будет.
А вот у шаблонной магии есть некоторые ограничения через которые не всегда можно переступить.
Здравствуйте, _NN_, Вы писали:
_NN>Зачем пост ?
затем, что надеялся, что кто-то предложит что-то оригинальное, но не сторонний кодогенератор.
_NN>Только перед сборкой нужно сгенерировать код.
не только.
_NN>Что означает в данном случае in-place ?
ну, т.е. сторонние кодогенераторы генерят в какой-то отдельный файл, который потом нужно использовать при сборке — это не in-place. in-place — это как сейчас, никакой сторонней кодогенерации, компилятор сам генерит все необходимое.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, _NN_, Вы писали:
_NN>>Зачем пост ? X>затем, что надеялся, что кто-то предложит что-то оригинальное, но не сторонний кодогенератор.
Я имел ввиду post-build
_NN>>Только перед сборкой нужно сгенерировать код. X>не только.
_NN>>Что означает в данном случае in-place ? X>ну, т.е. сторонние кодогенераторы генерят в какой-то отдельный файл, который потом нужно использовать при сборке — это не in-place. X>in-place — это как сейчас, никакой сторонней кодогенерации, компилятор сам генерит все необходимое.
Конечно это приятней чем добавлять ещё сборку сбоку.
Вон протобафу уже сколько лет, а так и нет автоматической нормальной интеграции в проекты VS.
Надо вручную вызвать генератор и при смене версии не забыть обновить пути.
Неплохо очень без кодогенератора, но очень плохо с другой стороны.
Кстати, а как код для Python и JS создаётся, не вручную же надеюсь ?
Здравствуйте, _NN_, Вы писали:
_NN>Я имел ввиду post-build
тогда, чтоб скомпилять сгенеренные сорцы.
_NN>Вон протобафу уже сколько лет, а так и нет автоматической нормальной интеграции в проекты VS. _NN>Надо вручную вызвать генератор и при смене версии не забыть обновить пути.
ужос %)
_NN>Кстати, а как код для Python и JS создаётся, не вручную же надеюсь ?
у меня нет этого кода, его пилила другая команда, которая разрабатывала клиентов.
у меня нет пока времени чтоб закодить парсер YAS-архивов для других ЯП...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
_NN>>Я имел ввиду post-build X>тогда, чтоб скомпилять сгенеренные сорцы.
Компилировать в любом случае нужно.
_NN>>Вон протобафу уже сколько лет, а так и нет автоматической нормальной интеграции в проекты VS. _NN>>Надо вручную вызвать генератор и при смене версии не забыть обновить пути. X>ужос %)
Вроде как в этом году наконец придёт счастье.
_NN>>Кстати, а как код для Python и JS создаётся, не вручную же надеюсь ? X>у меня нет этого кода, его пилила другая команда, которая разрабатывала клиентов. X>у меня нет пока времени чтоб закодить парсер YAS-архивов для других ЯП...
Зачастую проект не ограничивается одними плюсами и тут кодогенерация нужна будет по любому.