Это замечательный вопрос! Все именно так, как вы говорите. В изначальном примере создается как раз-таки raw pointer, по крайней мере, разбираясь в этом вопросе я не нашел подтверждения обратного. И никто не позаботится о них в случае каких-то форс-мажоров. Именно поэтому, я использую в своих фильтрах только shared_ptr. На нашем обожаемом stackoverflow я нашел подходящее решение для феникса Phoenix make_shared. Как раз его-то я и использую тут:
Не совсем понимаю ваш вопрос. Вы спрашиваете почему фронт фильтрует данные бэка, я правильно понимаю? Но ведь это именно бэк фильтрует, фронт только сообщает какие данные ему нужны. Условно запрос будет выглядеть как-то так:
Я работаю со связкой conan + cmake + ninja + clang8. Если «на холодную», то есть conan install, потом cmake, потом билд. То да, это прямо скажем небыстрый процесс, особенно, если зависимые библиотеки конан собирает на месте. Если же зависимости уже лежат готовые в ~/.conan/data, то я бы не сказал, что все так уж плохо. Вся библиотека(которая состоит из многих инструментов помимо фильтра) с тестами, которые проверяют и парсер в том числе, собирается за 2 минуты.
Это замечательный вопрос! Все именно так, как вы говорите. В изначальном примере создается как раз-таки raw pointer, по крайней мере, разбираясь в этом вопросе я не нашел подтверждения обратного. И никто не позаботится о них в случае каких-то форс-мажоров. Именно поэтому, я использую в своих фильтрах только shared_ptr. На нашем обожаемом stackoverflow я нашел подходящее решение для феникса Phoenix make_shared. Как раз его-то я и использую тут:
Очень рад, что этот материал вас порадовал)
Не совсем понимаю ваш вопрос. Вы спрашиваете почему фронт фильтрует данные бэка, я правильно понимаю? Но ведь это именно бэк фильтрует, фронт только сообщает какие данные ему нужны. Условно запрос будет выглядеть как-то так: