Когда-то давно многие ругались, что ошибки с std::vector или std::map выливаются в 5 экранов ошибок что-то там про шаблоны. К счастью, почти все компиляторы сегодня дают почти всегда одну строчку ошибки, но вот этот вот модальный std::expected - это 5 экранов ошибок шаблонной магии.
Кстати, часто ещё приходится писать не просто std::expected<User, AuthenticationError>, а что-то типа std::expected<std::unique_ptr<User>, AuthenticationError>, что делает ошибки примерно на 10 экранов шаблонной магии. Плюс надо следить за тем, чтобы возвращаемый std::expected строился в таком случае std::in_place, а не создавались временные объекты и конструкторы перемещения.
Также в C++23 добавили монадные функции к std::optional (который появился с C++17). К сожалению, не получается вместе использовать std::expected и std::optional столь же красиво.
Кстати, в своих проектах я уже некоторое время использую std::expected от https://github.com/TartanLlama/expected который работает начиная с древнего g++ 4.8 и clang++ 3.5.
Можно в очередь класть std::variant<> из C++17 с вашими типами. Если sizeof ваших типов примерно одинаковый, то вообще всё хорошо. Внутри в std::variant<> уже происходит вся магия с полиморфизмом, и не надо писать самому так подробно.
а вот достаточно серьёзный минус модели в том, что она очень убедительно умеет фантазировать и давать на первый взгляд логичные объяснения неверных ответов.
Типичный дилетант, понахватался по верхам, сыплет умными словами, и даже в контекст аккуратно вписывает, а смысла всё равно не понимает. Это если бы я посещал какие-нибудь семинары в медицинском, потом бы с умным видом говорил про белок и прочие T cells.
Слишком просто хайпануть на главном вопросе всех интервью про "Большое О", но сложнее (а) донести до новичков мысль, (б) дать полезную информацию уже чуть опытным. IMHO, больше всех в этом вопросе удалось автору книжки "Cracking the Coding Interview".
Особенно доставляет, когда начинают какие-то оптимизации придумывать на основе знаний, где и что конкретный компилятор положит, или хитрое использование UB. Например, почему нельзя просто взять и собрать Linux kernel не GCC, а clang? Или забавные интервьюеры ещё попадаются, которые очень каверзные вопросы про C++ спрашивают, думают, что если закастить указатель на объект на что-то там, и получить доступ к v-table, и что-то там ещё хитро съоптимизировать.
Я то думал, сейчас будет как на flutter, только на языке Go, а тут только треугольнички рисовать и никаких виджетов, ни нативных платформенных, ни библиотекой нарисованных.
Хотелось узнать подробнее о API ключах к платным сервисам Гугла. У меня есть аккаунт, я плачу денежку, я могу создать API ключи, а дальше я этот ключ прямо хардкожу в приложение? Есть какой-то механизм ротейта ключа? А если кто-то достанет ключ из приложения и начнёт пользоваться вне приложения, то это будет увеличивать мой счёт от Гугла потом?
Одно время, для расширения функциональности, использовали perl модули, экспортируя разные переменные, можно было выполнять какую-то работу на perl и запускать одну из функций из "бакенда" в конце, или просто возвращать какое-то значение, как фильтр.
Потом perl стал менее популярным, и запускать какой-то внешний python стало стильно/модно/молодёжно. Параллельно с этим некоторые проекты включали V8 для выполнения какой-то кастомной логики.
И получается, что следующее развитие - это WASM платформа, ведь в неё можно накомпилировать из чего угодно? Так можно было бы и просто джава-машину запускать, там бы и Jython работал.
Бежать срочно смотреть в сторону прогрессивных новых языков. 2022ой принёс нам их 3 штуки, выбирай
Val https://www.val-lang.dev
Carbon https://github.com/carbon-language/carbon-lang
CppFront https://github.com/hsutter/cppfront
Но, боюсь разочаровать здесь многих присутствующих, но "Это те же самые коды возврата" ;-)
Когда-то давно многие ругались, что ошибки с std::vector или std::map выливаются в 5 экранов ошибок что-то там про шаблоны. К счастью, почти все компиляторы сегодня дают почти всегда одну строчку ошибки, но вот этот вот модальный std::expected - это 5 экранов ошибок шаблонной магии.
Кстати, часто ещё приходится писать не просто std::expected<User, AuthenticationError>, а что-то типа std::expected<std::unique_ptr<User>, AuthenticationError>, что делает ошибки примерно на 10 экранов шаблонной магии. Плюс надо следить за тем, чтобы возвращаемый std::expected строился в таком случае std::in_place, а не создавались временные объекты и конструкторы перемещения.
Также в C++23 добавили монадные функции к std::optional (который появился с C++17). К сожалению, не получается вместе использовать std::expected и std::optional столь же красиво.
Кстати, в своих проектах я уже некоторое время использую std::expected от https://github.com/TartanLlama/expected который работает начиная с древнего g++ 4.8 и clang++ 3.5.
Зачем класть что угодно, это же не Python. В задаче было сказано, что бывают сообщения двух типов, вот их и будем класть.
Можно в очередь класть std::variant<> из C++17 с вашими типами. Если sizeof ваших типов примерно одинаковый, то вообще всё хорошо. Внутри в std::variant<> уже происходит вся магия с полиморфизмом, и не надо писать самому так подробно.
Типичный дилетант, понахватался по верхам, сыплет умными словами, и даже в контекст аккуратно вписывает, а смысла всё равно не понимает. Это если бы я посещал какие-нибудь семинары в медицинском, потом бы с умным видом говорил про белок и прочие T cells.
Зачем там длинно писать и указывать тип два раза, когда make_unique уже идёт с типом.
Вы обошли стороной Qt | Cross-platform Software Design and Development Tools
iPhone SE первый версии уже в пролёте, он останется на 15ой версии :-(
Слишком просто хайпануть на главном вопросе всех интервью про "Большое О", но сложнее (а) донести до новичков мысль, (б) дать полезную информацию уже чуть опытным. IMHO, больше всех в этом вопросе удалось автору книжки "Cracking the Coding Interview".
Особенно доставляет, когда начинают какие-то оптимизации придумывать на основе знаний, где и что конкретный компилятор положит, или хитрое использование UB. Например, почему нельзя просто взять и собрать Linux kernel не GCC, а clang? Или забавные интервьюеры ещё попадаются, которые очень каверзные вопросы про C++ спрашивают, думают, что если закастить указатель на объект на что-то там, и получить доступ к v-table, и что-то там ещё хитро съоптимизировать.
У меня пико-проектор Laser Beam Pro C200 Projector, кажет на всю стену, сама коробочка как толстый айфон.
Я то думал, сейчас будет как на flutter, только на языке Go, а тут только треугольнички рисовать и никаких виджетов, ни нативных платформенных, ни библиотекой нарисованных.
Программистам на Golang сейчас обидно стало.
Envoy сейчас в моде для таких клауд-шмауд дел. А главная фишка у него, что он умеет gRPC проксировать, а не просто на уровне HTTP.
Хотелось узнать подробнее о API ключах к платным сервисам Гугла. У меня есть аккаунт, я плачу денежку, я могу создать API ключи, а дальше я этот ключ прямо хардкожу в приложение? Есть какой-то механизм ротейта ключа? А если кто-то достанет ключ из приложения и начнёт пользоваться вне приложения, то это будет увеличивать мой счёт от Гугла потом?
Главное потом такое генератор натренировать на большом объёме данных, например, на всем GitHub, то получится.. GitHub Copilot
А что он там, количество своих девайсов спалил?
Одно время, для расширения функциональности, использовали perl модули, экспортируя разные переменные, можно было выполнять какую-то работу на perl и запускать одну из функций из "бакенда" в конце, или просто возвращать какое-то значение, как фильтр.
Потом perl стал менее популярным, и запускать какой-то внешний python стало стильно/модно/молодёжно. Параллельно с этим некоторые проекты включали V8 для выполнения какой-то кастомной логики.
И получается, что следующее развитие - это WASM платформа, ведь в неё можно накомпилировать из чего угодно? Так можно было бы и просто джава-машину запускать, там бы и Jython работал.
Если вы всё ещё не понимаете memory order, все эти seq_cst, relaxed, acquire/release, то мне помогла статья GCC Wiki AtomicSync, и вам рекомендую.