Конструируем музыкальный плеер PSG-файлов на чипе AY-3-8910 с OLED-экраном, кнопками управления и дополнительной памятью, а также подключаем выходные и входные сдвиговые регистры и прочие устройства с интерфейсами I2C и SPI к Arduino.
Всем привет.
Давно читаю хабр, давно и регулярно читаю статьи про правильное программирование.
В большинстве из них так же регулярно проявляется удивительная забота программистов об эстетической стороне программирования; мол, писать необходимо красиво, читабельно и выразительно. Сочетание этих трех добродетелей обычно вызывает у меня смех, и я объясню почему.
TLDR: забейте на читабельность и выразительность. Стремитесь сделать ваш код хорошо работающим..
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
На Flutter`е очень удобно и хорошо пишутся интерфейсы для пользователей. Но использовать Dart для решения алгоритмических задач тяжко и неэффективно. Семейство Си справляется гораздо лучше и позволяет легко распараллеливать вычисления. Кроме того, за многолетнюю историю С++ и С# обзавелись множеством полезных библиотек, не все из которых имеют аналоги во Flutter.
Зная про существование библиотеки FFI для Flutter, что позволяет даже синхронно запускать Си-шный код, я решил закопаться в эту тему и попробовать объединить наследие Си и их эффективность с удобным фреймворком. Учитывая то, что в интернете маловато информации про использование FFI, особенно с C#, я решил поделиться своим опытом "построения мостов" на примере двух приложений в этой статье.
Одним из главных нововведений стандарта C++20 является добавление модулей. Модули призваны радикально изменить структуру кодовых баз C++ и, возможно, сигнализируют о грядущей кончине заголовков (но, скорее всего, не на моем веку). Они также потенциально открывают дорогу для внедрения унифицированной системы сборки и менеджера пакетов, наподобие Rust Cargo; хотя я не сомневаюсь, что стандартизация унифицированной системы сборки будет тем еще кровавым побоищем.
Привет, Хабр! Меня зовут Михаил, я backend-разработчик в SimbirSoft. Время от времени я сталкиваюсь с понятием «двоичный», он же «бинарный» интерфейс приложений, или просто ABI (application binary interface). Все найденные мной материалы на эту тему были либо очень скудны, либо вели к многостраничным эпопеям, которые напоминали сборную солянку из описания, например, архитектуры процессора x86, сдобренную стандартом С++.
Но потом я наткнулся на перевод публикации Тита Винтерса в рабочей группе 21 (WG21) — комитета по стандартизации языка C++. В ней он поднимает вопрос поддержки обратной бинарной совместимости. Значит, вопрос актуальный — это и стало мотивацией для написания этой статьи. В ней я сфокусируюсь на примерах и практике использования С++ в других языках программирования. Материал будет полезен middle+ и senior-разработчикам, а также всем, кто хочет сделать гибкий, долгоживущий, легко настраиваемый под заказчика продукт.
Так что заваривайте чай, запасайтесь быстрыми углеводами — вас ждёт увлекательное погружение в мир низкоуровневого программирования. Начнём с теории, затем рассмотрим несколько практических примеров.
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Генерация пещер. Генерация на языке программирования С++, на основе клеточных автоматов с регулируемыми настройками.
Итак, судьба снова свела вас с C++, и вы поражены его возможностями с точки зрения производительности, удобства и выразительности кода. Но вот незадача: вы теряетесь в этом многообразии замечательных новых фич и, как следствие, затрудняетесь сходу определить, что из этого всего вам действительно стоило бы взять на вооружение в своей повседневной работе по написанию кода. Не стоит расстраиваться, в этой статье вашему вниманию будут представлены 21 новая фича современного C++, которые помогут сделать ваш проект лучше, а работу над ним легче.
Сообщество C++ дополняет стандарт чаще, чем Apple выпускает новые iPhone. Благодаря этому C++ теперь больше похож на большого слона, а съесть целого слона за один присест невозможно. Вот почему я решил написать эту статью, чтобы дать вашему путешествию по современному C++ своего рода отправную точку. Моя целевая аудитория здесь — люди, которые переходят со старого (т.е. 98/03) С++ на современный (т.е. 2011 и далее) С++.
Я отобрал ряд фич современного C++ и постарался объяснить их на лаконичных примерах, чтобы вы научились определять места, где их можно использовать.
В конце 2022 года открытый игровой движок Героев Меча и Магии 2 (fheroes2) добрался до заветной 1.0 версии. Несколько лет назад на Habr уже была новость о движке, когда текущие разработчики только-только взялись за него. Возможно, кому-то было бы интересно узнать о прогрессе и планах проекта на будущее.
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Работая в компании Gaijin несколько лет назад, мне довелось поучаствовать в портировании пары игр компании на консоль Nintendo Switch, тогда вовсю завоевывающую новые рынки. Для меня это стало первым крупным проектом на этой платформе. А с учетом, что ни команда, ни разработчик движка с платформой, системой сборки и вообще экосистемой Нинтендо знакомы не были, то все грабли приходилось искать и бережно на них наступать. Чтобы опробовать возможности новой платформы, параллельно с портированием игры, был написан внутренний middleware (связка dagor engine + nxsdk + jam) и код обрастал всевозможными тестами, build matrix, бенчмарками, прогоном стабильности и другими внутренними проверками. Надо отметить что на момент 2018 года, в самом switch sdk не было реализовано часть posix функций вроде poll и send/receive, и большая часть функций для работы с файлами, posix прослойку нужно было писать самим. Дошли тогда руки и до написания различных бенчмарков для функций стандартной библиотеки, и были замечены некоторые аномалии в поведении части тригонометрических функций в различных режимах сборки. Для справки, sdk использует урезанный вариант musl libc (https://www.musl-libc.org/), все статически линкуется в один большой бинарник clang'ом от Нинтендо 9 версии (2018 год), который потом запускается на консоли. Доступа к исходникам самой libc в исполнении Нинтендо у нас не было, но всегда можно посмотреть дизасм и боле менее представить что происходит.
В одном недавнем подкасте о том, кто сейчас главный в Rust, вновь всплыл вопрос о том, кому быть BDFL (великодушным пожизненным диктатором), и Джереми Соллер сказал (это был чемпионский заход на приз «за преуменьшение века»): «Я считаю, Грейдон забраковал бы некоторые вещи, которые всем нам сейчас нравятся». Этим он вторит другой дискуссии на reddit, в которой мне напомнили, что я собирался как-нибудь расписать, каким образом «я сделал бы всё по-другому». Вероятно, это бы крайне не понравилось всем причастным, и эти идеи далеко бы не распространились.
Ну и ну. Я понял, что следующий момент не вполне очевиден и он, пожалуй, заостряет вопрос, «а действительно ли в проекте нужен BDFL». Так вот, озвучу его: Rust Нашего Времени далеко, далеко отстоит от Rust Моей Мечты. Главное, не поймите меня неправильно: мне нравится, что у нас получилось. Получилось отлично. Я воодушевлён, что теперь есть столь жизнеспособная альтернатива C++, в особенности такая, которую другие люди уже начинают воспринимать как норму, как реальный вариант для повседневной работы. Я пользуюсь Rust и очень доволен, что могу отдавать ему предпочтение перед C++. Но!
Я столько всего сделал бы в Rust по-другому, если бы всё это время «отвечал» за его развитие.
Хранение сотояния в виде набора полей примитивных типов, расположенных в определённом порядке, - очень старый паттерн, впервые напрямую поддержанный в записях Cobol в 1959 году. В наши дни он активно применяется при хранении данных в памяти (структуры, классы, массивы) и на диске (бинарные файлы, записи баз данных), при передаче данных по сети (бинарные протоколы), при передаче аргументов в функции (соглашения о вызове), при хранении переменных на стеке (и доступе к ним из отладчика) и так далее.
В данной статье я хочу показать принятую в нашем проекте организацию работы с подобными наборами полей в стиле C++ - через соответствующие типы итераторов.
OpenAI предоставляет мощные инструменты для работы с GPT-3 и GPT-4. Однако возможность подсчёта токенов реализована только для JavaScript и Python, что не покрывает всех возможных вариантов использования. В связи с этим я разработал универсальную библиотеку GPT-Tokenator для подсчёта токенов на C++, экспортировал функцию подсчёта токенов в C, что даёт возможность использовать её во многих языках программирования.
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
