Привет, Хабр!
Сегодня я хочу поговорить о двух правилах С++: правиле трех и правиле пяти.
Правильное понимание этих правил способно уберечь код от утечек и неопределенных поведений.
Типизированный язык программирования
Привет, Хабр!
Сегодня я хочу поговорить о двух правилах С++: правиле трех и правиле пяти.
Правильное понимание этих правил способно уберечь код от утечек и неопределенных поведений.
Всем привет!
Пришла, значит, мне в голову идея - сделать свою игру по типу Vampire Survivors и Brotato, а потом я подумал, что можно еще и цикл статей написать про то, как я ее разрабатываю, вдруг кому-то это покажется полезным (ну или хотя бы смешным).
Ну, собственно, вот - первая часть. В ней я покажу, как я создал персонажа и научил его бегать.
Заходят как-то на Хабр С++ разработчики из крупных компаний, а у них спрашивают: что такое код-ревью и используют ли они спецификатор final. Эти и другие вопросы с подвохом мы задали инженерам из YADRO, VK, Kaspersky, Syntacore и PVS-Studio. В итоге обсудили инструменты для работы со сторонними зависимостями, интерфейсы «плюсовых» библиотек и отказ (или нет) от exceptions.
Продолжим дискуссию на митапе по С++, который пройдет онлайн 20 марта. Регистрируйтесь, подключайтесь к трансляции и пишите вопросы и комментарии в чат — ведущие озвучат некоторые из них.
В МойОфис мы создаем ПО для корпоративного пользования, и одни из ключевых продуктов нашей линейки — редакторы документов «МойОфис Текст» и «МойОфис Таблица». Эти приложения представлены на всех популярных платформах, включая мобильные устройства. Они позволяют создавать, изменять, просматривать текстовые и табличные документы различных форматов, а также совместно работать над ними в веб-версии редакторов.
Сегодня мы расскажем об общем технологическом устройстве редакторов МойОфис, с акцентом на их центральный элемент: ядро, написанное на C++. Именно ядро обеспечивает основную функциональность приложений и даёт нам возможность эффективно унифицировать её для разных платформ.
О том, что представляет собой ядро наших редакторов, принципах его работы, преимуществах и специфике, читайте под катом.
Асинхронность... Как много в слове этом! Асинхронность считается одной из сложных тем программирования вообще. Не все просто в этом вопросе. В интернете периодически появляются различные статьи, туториалы по тем или иным вопросам асинхронности. Из последнего дельной статьей я считаю вот этот материал. Собственно, эта статья и послужила последней каплей, переполнившей моё терпение. Мною сделана попытка взглянуть на асинхронность, проблемы и сложности, связанные с ней, совершенно под другим углом. Выводы, я бы сказал, напрашиваются весьма радикальные. Итак, поехали!
Год назад я начал изучать программирование, но когда во всех обучениях просили создать консольную игру, я пропускал это дело. Но тут стало интересно, как это вообще происходит. И решил сделать динозаврика из гугл в консоли.
Наверняка вы создавали open source проекты и выкладывали их на GitHub, но я уверен, что очень немногие из вас создавали документацию для этих проектов. В этой статье я расскажу, как создавать и публиковать доки максимально просто.
Документация будет создаваться на основе исходного кода, она будет обновляться при каждом коммите и при этом будет доступна через интернет. Документирование происходит через Doxygen, в качестве хостинга выступает GitHub, а за обновление документации отвечает GitHub Pages.
Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.
В данной небольшой статье я предлагаю рассмотреть как работает принцип RVO (return value optimization) в компиляторе gcc. Автор статьи не претендует на уникальность и какую-то новизну. Ориентировано на начинающих и представляет собой больше некую заметку.
Итак, рассмотрим класс и код, его использующий:
Некоторые паттерны стало возможно использовать на практике только благодаря безопасности Rust по памяти, а на C++ они слишком опасны. В статье приведён один такой пример.
Работая над внутренней библиотекой, написанной на Rust, я создал тип ошибок для парсера, у которых должна быть возможность сделать Clone
без дублирования внутренних данных. В Rust для этого требуется указатель с подсчётом ссылок (reference-counted pointer) наподобие Rc.
Поэтому я написал свой тип ошибок, использовал его как вариант ошибок fallible-функций, и продолжил двигаться дальше.
Ещё недавно, как я начал изучать веб хакинг, я счёл интересным занятие исследовать Linux и Windows на предмет бинарных уязвимостей. Хотя легально заработать в одиночку хакером у нас в России я думаю можно только веб хакингом, я всё равно хочу изучать все интересующие аспекты атакующей и защищающей стороны. Кто знает, вдруг я когда-нибудь буду в red team. Ну а пока я просто грызу гранит науки.
Слегка поразмыслив над решением задачи, я определил что нужно для осуществления моей проблемы. Я не знаю как другие проводят фаззинг библиотек, у которых нет исходных текстов, но додумался до одного варианта. Далее будут два примера для Linux и Windows.
Командный центр PVS-Studio: "Как быстро летит время... А ведь в этом году, второго января, Blender исполнилось 30 лет! Как будто ещё вчера мы публиковали статью с разбором ошибок... Как 8 лет назад? Надо срочно исправлять ситуацию!".
Недавно я наткнулся на пост Алехандры Гонсалес (@blyxyas), в котором рассказывается о попытке сжать игру крестики-нолики в минимальное количество битов. Она пришла к решению из 18 битов. Это заставило меня задуматься: а можно ли улучшить этот результат?
Как говорит Алехандра, существует 765 возможных состояний игры1. Мы можем просто назначить число каждому состоянию, что займёт 10 битов2. Но, по словам Алехандры, это «скучно». С таким описанием игры мы практически ничего не сможем сделать. Когда будет нужно считать значение из конкретной ячейки или перейти из одного состояния в другое, на практике нам придётся использовать таблицу поиска, сопоставляющую каждое число с более крупным и структурированным описанием, что делает бессмысленным саму идею сжатого описания.
20 марта собираемся на бесплатном митапе в Санкт-Петербурге и онлайн. Константин Владимиров расскажет о цене абстракции, а разработчик из команды телекома YADRO Владимир Леонтьев на примере инструмента генерации RPC-серверов покажет, как написать кодогенератор. В конце встречи создатель Sprinx Андрей Аксенов, разработчик VK AdTech Станислав Юрченко, техлид Kaspersky Александр Еналдиев и разработчик YADRO Илья Казаков вместе с гостями и зрителями митапа обсудят тонкости код-ревью.
В этом материале делимся программой митапа. Регистрация уже открыта — переходите по ссылке и заполняйте форму, чтобы присоединиться к мероприятию.
Мой выбор остановился на простецкой игре - виселице, запускаемой в консоли, которую я решил написать на С++. Здесь я хочу рассказать о том, как я её реализовал, что использовал и т.д.
Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это седьмая статья из серии, список предыдущих статей приведен в конце в разделе 10. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена концепции константности в C++.
Переменные являются основой любого языка программирования. Если значение переменной нельзя изменить после инициализации, то такие переменные называются неизменяемыми (immutable) переменными или константными переменными или просто константами. Константные переменные в том или ином виде поддерживаются во всех языках программирования и играют в них важную роль. Такие переменные помогают компилятору оптимизировать код, улучшают читаемость и надежность кода, позволяют выявлять бОльшее количество ошибок на стадии компиляции. Константы помогают решать проблемы, связанные с многопоточным доступом к переменным. Использование константных переменных влияет на проектные решения в объектно-ориентированном программировании, а функциональное программирование изначально исходит из неизменяемости используемых переменных.
В C++ концепции константности уделяется значительное место. Для переменных используется два вида константности, имеются ссылки и указатели на константу, константные функции-члены, константные итераторы. Попробуем разобраться во всех этих понятиях.
Хотел написать продолжение к статье Что почитать игровому программисту? про использование С++ в игровых движках, но размышления свернули куда-то не туда.
Завороженно смотрю как и какими темпами идет развитие языка в последние годы, и понимаю, что получить и особенно применить возможности С++20/3 в разработке игр и движков получится хорошо, если с опозданием лет эдак в пять, как раз на следующее поколение консолей, если вообще получится. Сейчас плюсы в игрострое зависли где-то между 14 и 17 стандартом, Сони только-только выкатила свою версию компилятора с полной поддержкой 17 стандарта, а учитывая реактивность игровых студий в изменении кор пайплайнов, что-то новое начнут только в новых проектах. Менять коня, т.е. компилятор посреди разработки игры равносильно стрельбе не только по ногам себе, но и соседям программистам: работает - не чини.
Если смена компилятора и стандарта не даст гарантированного прироста скорости работы больше 5%, то бюджет и людей я не одобрю. (с)
Знакомство с кодовой базой больших движков дает понимание уровня и объёмов кода в продакшене и в тулзах, и ситуация вырисовывается такая, что эти объемы стали в индустрии, что называется "too big to fall", т.е. написать что-то новое, уровня движков вроде Unity/Unreal/Dagor на другом языке, будь он хоть в тысячу раз безопаснее и в десять раз быстрее не получится, но попытки конечно делаются. И чем дальше продолжается поддержка существующих проектов на плюсах, тем меньше возможности выбора остается.
Все попытки прикрутить сбоку скрипты, виртуальную машину второго языка, визуальные редакторы скриптов, блупринты и т.д. лишь показывает насколько громоздким стал основной механизм. А игры прекрасно продаются на текущем стеке технологий, и обосновать переезд на новый стек мифическим рефакторингом, техдолгом и новыми технологиями не удаётся, поэтому мышки продолжают плакать и потреблять кактус++.
Ваш аккаунт