Приветствую Хабравчане!
В прошлой статье получилось создать минимальную программу "Hello world!" размером 3,5 кб. Теперь будем рисовать нативными средствами Windows.
Проблема безопасной разработки на С++ возникла не вчера, и она достигла таких размеров, что рекомендации использовать более надежные языки программирования, принимаются на самом высоком уровне.
Но даже несмотря на наличие подобных рекомендаций, планы прекратить использовать С++ и перейти любой другой безопасный язык программирования, часто не выдерживают обычных финансовых расчетов. Ведь если отказаться от С++, то что придется делать с миллионами или даже миллиардами строк кода, которые были написаны за несколько предыдущих десятилетий?
К сожалению, и сам С++ не особо стремится стать более "безопасным". Точнее, подобное стремление плохо сочетается с требования к стандарту языка, которые принимаются комитетом по стандартизации С++. Ведь любой стандарт должен обеспечивать обратную совместимость со всем старым легаси кодом, что автоматически сводит на нет любые попытки внедрения какой либо новой лексики на уровне единого стандарта С++.
И в этой ситуации правы те, кто выступает за обязательную поддержку обратной совместимости со старым кодом. Но правы и те, кто считает необходимым добавление новых возможностей для безопасной разработки на С++ хотя бы в новых проектах.
Таким образом, возникают, казалось бы, взаимоисключающие и не разрешимые противоречия:
Но ключевым моментом в предыдущем абзаце является фраза "казалось бы".
Данной статьей я хочу продемонстрировать процесс погружения в неизвестную сферу, методы и средства для сбора информации. Чтобы раз и навсегда закрыть вопрос какие материалы “почитать”, ведь, действуя по гайду “я повторил, но ничего не понял”.
Что именно будем делать? Попробуем без особых знаний залезть в исходники софта для отладки и модификации кода, под названием Cheat Engine. Он создавался годами, а наша задача — апроприировать эти знания за короткий промежуток времени!
Приветствую, Хабравчане!
Решил сделать цикл статей по написанию на С++, различных небольших программ. Под новые и старые ОС. Мне кажется мы стали забывать как раньше программировали:) Для себя определил несколько важных критериев.
Мне показалась очень интересной тема открытая в недавней статье
Собрал в одном большом гайде всё, что хотел бы знать, когда изучал язык C
Во вступлении там написано:
"Очевидный факт: язык C — это основа большого количества современных экосистем программирования. Он обеспечивает фундамент многих операционных систем, базовых библиотек и системных инструментов."
Мне кажется полезно все таки обозначить в каком смысле язык C — это основа, и чем он обеспечивает фундамент. Я рад что имею возможность сформулировать что-то в данном направлении не со слов иностранного авторитета, а не базе собственного опыта который, тем не менее, формировался на основе анализа-применения действующих решений-теорий сформулированных во многом иностранными специалистами, но надеюсь с примесью собственной креативности в какой-то степени. Ну и хочется озвучить свой ответ на вопрос: "Когда C — идеальный выбор?", может в интерпретации: "А бывает ли язык Си идеальным выбором?"
По моему, тема очень полезная, хотелось бы увидеть и поддержать ее развитие.
Еще одна статья в продолжение темы анализа сходных текстов на С/С++ с помощью Clang. Предыдущие публикации:
Это не перевод довольно подробной публикации Emitting Diagnostics in Clang от Peter Goldsborough про различные нюансы диагностических инструментов у Clang, а преимущественно адаптация старого кода под текущую версию компилятора.
И основная идея, которая меня заинтересовала в исходной публикации, это использование инструмента FixIt из набора диагностики clang для внесения исправлений в исходные файлы.
В этой статье описано создание эмулятора 16-битной приставки Sega Mega Drive на C++.
Будет много интересного: эмуляция процессора Motorola 68000, реверсинг игр, графика на OpenGL, шейдеры, и многое другое. И все это на современном C++. В статье много картинок, можно хоть на них посмотреть.
Новогодние каникулы — отличное время не только для отдыха, но и для саморазвития. Если вы хотите узнать больше о низкоуровневой оптимизации, тонкостях работы с GPU или разобраться в архитектуре ядра Linux, эти выпуски подкаста «Битовые Маски» точно стоит добавить в свой плейлист. Эксперты с многолетним опытом обсуждают самые сложные темы из мира низкоуровневого программирования, делятся ценными инсайтами и реальными историями из профессиональной практики.
Во время разработки на Unreal Engine могут возникнуть задачи, которые требуют автоматизации, повторяемых действий или пакетной обработки. Эти задачи могут варьироваться от компиляции Blueprint'ов до упаковки игры на удаленном сервере. В таких случаях на помощь приходят Commandlet'ы.
Я на них наткнулся случайно, когда при запаковке проекта было много ошибок и было нужно пройтись по всем Blueprint — классам в проекте чтобы проверить, правильно ли они компилируются после изменений в C++. В данной статье хотелось бы поделиться опытом своего знакомства с ними.
В продолжение темы кастомизации компилятора С++ публикую перевод еще одной интересной статьи от Eli Bendersky AST matchers and Clang refactoring tools.
Инструментарий Clang вызывает большой интерес и внимание к разработке в последние годы. Наконец-то у нас есть удобный, точный, с открытым исходным кодом и хорошо поддерживаемый фреймворк для программного анализа и рефакторинга кода C++ и это я нахожу это очень захватывающим!
Прекрасным результатом этого быстрого темпа разработки является то, что постоянно появляются новые API и инструменты.
Например, некоторое время назад разработчики инструментария Clang выяснили, что людям, выполняющим обходы AST, приходится писать много повторяющегося кода, чтобы найти нужные им узлы AST, поэтому они придумали отличный новый API под названием AST matchers.
Статическая рефлексия обсуждается в грядущем C++26. Wu Yongwei демонстрирует, как применять рефлексию сейчас, и показывает примеры того, что может будет возможным в C++26.
Статическая рефлексия будет важной частью программирования времени компиляции программы на C++, как я рассказывал в октябрьском выпуске Overload. Здесь мы обсудим детально статическую рефлексию, включая, как эмулировать её прямо сейчас, до того, как она будет добавлена в Стандарт.
Это перевод статьи, которая, к сожалению, у меня не доступна без слова из трех букв. А так как тема довольно интересная, то я решил совместить полезное с полезным и не только самому покопаться с примерами из публикации, но и сделать её перевод на Хабре. Вдруг еще кому данный материал будет интересен?
Создание пользовательского расширения компилятора C++ подразумевает понимание базовых механизмов работы компиляторов, изменение или расширение их функциональности и бесшовную интеграцию этих изменений в существующую инфраструктуру компилятора. Это руководство проведет вас через весь процесс, от понимания основ до внедрения и тестирования вашего пользовательского расширения. Целевая аудитория этого руководства — разработчики, которые уже знакомы с C++ и имеют базовое понимание концепций компилятора.
В этой статье мы рассмотрим классический конкурентный кольцевой буфер и обсудим, как его можно оптимизировать для повышения производительности. Я покажу вам, как существенно улучшить этот показатель от 5,5 миллионов элементов в секунду до 112 миллионов элементов в секунду — и эти показатели выше, чем в реализациях Boost и Folly. Если вам требуется готовая реализация со всеми этими оптимизациями, посмотрите мою библиотеку SPSCQueue.h.
Кольцевой буфер также называется очередью «один производитель — один потребитель» (SPSC). В ней не бывает ожидания (и, соответственно, не бывает блокировок), это конкурентный примитив. Такая структура данных находит множество вариантов применения, и здесь я рассмотрю передачу сетевых пакетов между сетевым контроллером и драйверами операционной системы. Основная задача, решаемая при этом — выполнение событий ввода/вывода в относительно новом асинхронном API io_uring.
Каждый год мы наблюдаем одинаковую картину: ошибки портят нам код, пытаясь доказать, что они здесь главные. Но сегодня настал день расправы. Давайте посмотрим, какие самые интересные баги мы нашли в этом году...
Привет, Хабр!
Однажды в детстве, когда я был у в гостях бабушки в деревне, я увидел в старенькой радиоле индикатор «зеленый глаз», который меня очень впечатлил. Его свечение было настолько красивым и магическим, что я даже подумал о каком-то внеземном происхождении данной штуки. Шли годы, я уже давно не ребенок, но до сих пор испытываю то чувство магии, когда вижу ламповый индикатор. И вот, в преддверии Нового Года, мне захотелось реализовать что-то ламповое и магическое в своем новом проекте, а что из этого получилось — читайте далее.
Случайно попалась довольно старая статья 2018 года с простым и понятным описанием категорий значений в C++. До неё всякие glvalues, prvalues, xvalues были малопонятными для меня.
cppreference.com просто перечисляет категории, и это не добавляет понимания, всё кажется чрезмерно излишним.
На stackoverflow.com есть 24 поста разной степени ценности, что только добавляет недоумения от сложности этой темы.
С выходом PVS-Studio 7.34 стали доступны нативные сборки анализатора для macOS на архитектуре Apple Silicon (ARM). В этой заметке мы хотели бы подробнее рассказать о проделанной работе, а также предложить советы по портированию кроссплатформенных инструментов на новую перспективную архитектуру.
Всем привет!
Начну с предыстории.
Когда мы в Амазоне планировали переносить сервис с x86/64 на ARM, почему-то никто в нашей команде не поднял тему того, что надо уделить особое внимание работе с многопоточностью и синхронизацией, так как из-за того, что у этих двух архитектур разные модели памяти, могли случиться неожиданные проблемы.
Однако, на тот момент я тоже об этом не знал, и нам повезло, что мы изначально везде использовали модель памяти Sequential Consistency (что это – далее в статье), поэтому все прошло гладко. Теперь, зная про модели памяти и возможные последствия, боюсь представить, что было бы в противном случае.
Как родилась статья
Когда я впервые изучал модели памяти, я мало что понял, и спустя месяц все забыл. Потом прочитал еще раз, но, к сожалению, тоже хватило ненадолго. В итоге я решил расписать все для себя максимально подробно, с красивыми картинками, чтобы при необходимости можно было к ним возвращаться и не тратить много времени на вспоминание.
Статья основана на материалах лекции Computer Science Center (CSC) с курса “Параллельные вычисления” преподавателя Калишенко Е.Л. Крайне рекомендую ознакомиться со всеми лекциями курса (более структурированного материала по теме я еще не встречал). Благо он в открытом доступе – ссылка.
Что такое барьеры памяти и зачем это все нужно?
Начнем с небольшого описания того, как устроена “условная” архитектура процессора. Почему условная? Потому что может отличаться в зависимости от конкретной реализации, но суть похожа.
Меня всегда удивляло как разработчики умудряются размещать большой объем вычислений на относительно слабом железе, к каким трюкам и решениям прибегают, чтобы приложение работало быстро, это относится не только к игровым движкам, но и базам данных, системам управления и т.д., но так как моя область это все же игры и игровые движки, то рассказывать я буду про них. Особенно заметна эта разница была при портировании относительно свежих игр (поколение ps3+) на всякие портативные консоли вроде Nintendo Switch, Apple TV (это девайс тоже считается неплохой платформой, в плане что там есть платящая аудитория) и мобилки. И свитч и appletv по производительности не сильно далеко ушли от третьей плойки, и попытки перенести требовательные игры, рассчитанные как минимум на следующее (ps4) поколение консолей, приводят к значительным проблемам, которые непросто решаются. Игры - это достаточно требовательный софт, зачастую с мягким реалтаймом, надо же выдавать приемлимый фпс - иначе играть будет больно, некомфортно и её никто не купит. Небольшим подспорьем при переносе на портативки и мобилки является их стабильное железо, хотя вот для мобилок я бы так не сказал, там целый зоопарк процов, видях и окружения. На консолях с этим все получше и спеки меняются раз в пару лет. Когда речь заходит о портировании игры - оптимизации можно разделить на несколько уровней: архитектура, алгоритмы и код.
Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024, выявляет критические ошибки и может использоваться при разработке безопасного программного обеспечения. Рассмотрим функциональные возможности, реализованные в PVS-Studio на конец 2024 года в отношении анализа исходного кода программного обеспечения, написанного на компилируемых языках программирования C, C++, C#, Java.
