1) Согласен что зло. Однако единственный способ отобразить произвольное выражение в виде массива символов - макросы вида `#define STRINGIZE(X) #X`
Задать произвольный namespace для большого фреймворка можно разными способами, и макрос - менее ужасающий из возможных вариантов
2) Мы и не используем Boost когда можно без него. В данном случае он необходим, так как на многих платформах где собирается userver авторы стандартных библиотек C++ помечают реализацию std::filesystem как experimental и неготовую к промышленному использованию
3) И правда некрасивенько. Можно будет поправить как-нибудь
4) Вы пропустили большую проблему в данном коде, сосредоточившись в ревью не на логике/архитектуре. Первый кто найдёт проблему до того как мы закомитим фикс, получит от нас маленький презент
Дигностика корректная - читать можно только из активного члена union. Об этом есть заметка и на cppreference ниже по тексту, и в первоисточнике https://eel.is/c++draft/class.union#general-2 . На практике большинство компиляторов C++ позволяют делать такие трюки через union, и пока ничего не ломается
На современных компиляторах варианты через memcpy и bit_cast работают столь же быстро как и union . Ну и как годно заметили в статье - bit_cast читать приятнее :)
В стандарт добавляют потому что это удобно. Да, можно написать простейшую утилиту, которая файл возвращает в виде цифр и запятых, которые можно заинклюдить препроцессорной директивой для инициализации массива, встроить запуск этой утилиты в систему сборки, предварительно компилируя её если нужно...
А можно стандартизировать #embed и всем будет удобно из коробки.
Весь процесс стандартизации направлен на удобство использлвания - можно обходиться без std::string, constexpr, auto, for, switch, std::map, std::vector... Можно писать эти классы самому, обходиться без автоматизации работы со стороны компилятора. Но будет не удобно
Сейчас комитет отошёл от идеи стандартизировать какой-то имеющийся пакетный менеджер или систему сборки. Вместо этого сосредоточились на создании стандартного языка описания зависимостей и сборки. Чтобы с таким файлом описания вы могли собрать проект и с помощью cmake, и с помощью basel, и с помощью conan...
Встроенный в язык способ преобразования строк в enum ожидается от статической рефлексии. Предложения по ней рассматриваются с повышенным приоритетом, все надёются увидеть рефлексию в C++26 (но лично я сомневаюсь, что успеем).
А std::any вам не подойдёт вместо std::object* ? Работает даже и не с полиморфными объектами
Напишите proposal с хорошей мотивацией. Пока что все попытки разбивались об отсутствие мотивации. Мотивация должна показывать, что с новой фичёй добавляются недоступные до этого возможности, код становится проще для понимания и компактнее. Так же надо продумать, что происходит при передаче property в шаблонную функцию foo(auto&), и как вообще property взаимодействуют с ADL.
Как у вас с обработкой ошибок? Умеем корректно отменять иерархию корутин, при возникновении исключения? Исключения поддерживаются? Бизнес ошибки же надо как-то передавать . . .
Всё хорошо, исключения работают из коробки, иерархии корутин автоматически отменяются м все деструкторы отрабатывают (RAII разумеется работает).
Пока Java программисты делают успешные проекты...
Наверное поэтому ПО для банковских терминалов, медицинского оборудования, самолётов, космических аппаратов и автомобилей, сапр написано на C++. Как кстати и userspace некоторых ОС, браузеры, игровые движки, интернет поисковики, таксишные и другие агрегаторы, рендеры для мультиков и блокбастеров, фотошопы и 3d моделирование, видеообработка, машинное обучение, распознавание образов, рассчёты для CERN и всякие поиски бозонов, химические и геодезическое ПО, компиляторы для вашей любимой Java, да и вообще большинство компиляторов, трансляторов и jit...
Если вы не сталкивались с успешной разработкой на C++, то посмотрите например туториалы и исходники того же userver. Откройте для себя современный C++, а не то `char* str = malloc(10);` подобное безобразие, что многие видели в бездарных учебниках начала века.
Мы это всё отловили специальными инструментами и заменили на неблокирующие чтения. Но если вы будете стороннюю библиотеку использовать с userver, то да, она может делать плохое. В документации описано, как с этим бороться
Именно так мы и пишем. Фреймворк проверит количество аргументов в вашем запросе и количество переданных параметров, превратит запрос в prepared statement... И когда выполнение дойдёт до строчки с запросом, по сети полетит идентификатор prepared statement и параметры в бинарном виде (не в текстовом как это делает libpq).
Есть ещё конечно ORM, но это отдельный проект и многие им не пользуются
1) Согласен что зло. Однако единственный способ отобразить произвольное выражение в виде массива символов - макросы вида `#define STRINGIZE(X) #X`
Задать произвольный namespace для большого фреймворка можно разными способами, и макрос - менее ужасающий из возможных вариантов
2) Мы и не используем Boost когда можно без него. В данном случае он необходим, так как на многих платформах где собирается userver авторы стандартных библиотек C++ помечают реализацию std::filesystem как experimental и неготовую к промышленному использованию
3) И правда некрасивенько. Можно будет поправить как-нибудь
4) Вы пропустили большую проблему в данном коде, сосредоточившись в ревью не на логике/архитектуре. Первый кто найдёт проблему до того как мы закомитим фикс, получит от нас маленький презент
Да, мы много где её используем
Весьма полезная штука)
Альтернативное мнение с бенчмарками и совсем другими выводами: Коды ошибок — это гораздо медленнее, чем исключения
Из двух статей можно составить более полную картину :)
Дигностика корректная - читать можно только из активного члена union. Об этом есть заметка и на cppreference ниже по тексту, и в первоисточнике https://eel.is/c++draft/class.union#general-2 . На практике большинство компиляторов C++ позволяют делать такие трюки через union, и пока ничего не ломается
На современных компиляторах варианты через memcpy и bit_cast работают столь же быстро как и union . Ну и как годно заметили в статье - bit_cast читать приятнее :)
В стандарт добавляют потому что это удобно. Да, можно написать простейшую утилиту, которая файл возвращает в виде цифр и запятых, которые можно заинклюдить препроцессорной директивой для инициализации массива, встроить запуск этой утилиты в систему сборки, предварительно компилируя её если нужно...
А можно стандартизировать #embed и всем будет удобно из коробки.
Весь процесс стандартизации направлен на удобство использлвания - можно обходиться без std::string, constexpr, auto, for, switch, std::map, std::vector... Можно писать эти классы самому, обходиться без автоматизации работы со стороны компилятора. Но будет не удобно
А ещё для тех, у кого платформа не предоставляет удобных механизмов для прилинковвывания произвольных файлов.
А ещё результат #embed доступен в constexpr, так что можно включать разлтчные таблицы констант и делать compile time вычисления над ними.
Работа идёт, и она в приоритете для C++26.
Сейчас комитет отошёл от идеи стандартизировать какой-то имеющийся пакетный менеджер или систему сборки. Вместо этого сосредоточились на создании стандартного языка описания зависимостей и сборки. Чтобы с таким файлом описания вы могли собрать проект и с помощью cmake, и с помощью basel, и с помощью conan...
В виде библиотеки принять в стандарт будет попроще :)
Звучит интересно! Готовы помочь с написанием предложения, но готовьтесь к тому что будет тяжко принять такое в стандарт...
А для каких именно случаев вам нужен такой указатель? Приведите пожалуйста примеры
Встроенный в язык способ преобразования строк в enum ожидается от статической рефлексии. Предложения по ней рассматриваются с повышенным приоритетом, все надёются увидеть рефлексию в C++26 (но лично я сомневаюсь, что успеем).
А std::any вам не подойдёт вместо std::object* ? Работает даже и не с полиморфными объектами
Напишите proposal с хорошей мотивацией. Пока что все попытки разбивались об отсутствие мотивации. Мотивация должна показывать, что с новой фичёй добавляются недоступные до этого возможности, код становится проще для понимания и компактнее. Так же надо продумать, что происходит при передаче property в шаблонную функцию foo(auto&), и как вообще property взаимодействуют с ADL.
Соптимизированный LRU как раз является частью userver https://userver.tech/d5/d9c/classcache_1_1LruSet.html
Так что сэкономили минимум 250 ядер :) Увы, более точные замеры сделать проблематично, но постараемся что-то придумать к релизу
Всё хорошо, исключения работают из коробки, иерархии корутин автоматически отменяются м все деструкторы отрабатывают (RAII разумеется работает).
Наверное поэтому ПО для банковских терминалов, медицинского оборудования, самолётов, космических аппаратов и автомобилей, сапр написано на C++. Как кстати и userspace некоторых ОС, браузеры, игровые движки, интернет поисковики, таксишные и другие агрегаторы, рендеры для мультиков и блокбастеров, фотошопы и 3d моделирование, видеообработка, машинное обучение, распознавание образов, рассчёты для CERN и всякие поиски бозонов, химические и геодезическое ПО, компиляторы для вашей любимой Java, да и вообще большинство компиляторов, трансляторов и jit...
Если вы не сталкивались с успешной разработкой на C++, то посмотрите например туториалы и исходники того же userver. Откройте для себя современный C++, а не то `char* str = malloc(10);` подобное безобразие, что многие видели в бездарных учебниках начала века.
Если нет асинхронной версии системного вызова, то ничего не остаётся кроме как вынести вызов в отдельный task processor ¯\_(ツ)_/¯
Можно в примере заменить на string_view, не суть важно :)
Мы это всё отловили специальными инструментами и заменили на неблокирующие чтения. Но если вы будете стороннюю библиотеку использовать с userver, то да, она может делать плохое. В документации описано, как с этим бороться
Подскажите, что именно вы предлагаете упростить?
Именно так мы и пишем. Фреймворк проверит количество аргументов в вашем запросе и количество переданных параметров, превратит запрос в prepared statement... И когда выполнение дойдёт до строчки с запросом, по сети полетит идентификатор prepared statement и параметры в бинарном виде (не в текстовом как это делает libpq).
Есть ещё конечно ORM, но это отдельный проект и многие им не пользуются
В то время был vendor lock на технологию - страшненько писать код на платформе, которую контролирует одна корпорация, с не самой хорошей репутацией.
Для ряда задач очень мешает GC, сталкивались на проде с проблемами.
Большая кодовая база на C++ и штат С++ специалистов подталкивают к использованию этого языка, как и некоторые CPU ресурсоёмкие задачи.