Большинство ошибок с памятью в C++ не выглядят как ошибки. Код компилируется, тесты проходят, приложение работает неделями. А потом внезапно появляется Segmentation fault, повреждённая куча или утечка памяти, которую приходится искать часами.
Разберём пять типичных ловушек, в которые регулярно попадают начинающие разработчики.
Хотели избежать копирования данных, придумали свою служебную разметку, а потом обнаружили: она занимает почти столько же места, сколько сам исходный текст. Мы перестали гадать, посмотрели на реальные данные и применили простые, но эффективные подходы: числа переменной длины, отказ от double в пользу целых типов и умные if-else вместо switch.
Итог: мы сжали разметку в 2,5 раза и при этом даже немного выиграли в скорости. Рассказываем, как знание предметной области помогло нам не усложнять код, а сделать его быстрее и легче.
В этой заметке мы разберём, что такое экспертиза и в чём её суть. Она бывает разной глубины, сферы и предназначения. Экспертиза не может существовать без теоретических знаний, опыта и, конечно же, не рождается там, где нет трудностей и ошибок. У каждого человека она уникальна.
Ещё несколько лет назад рефлексия считалась нормой для.NET‑приложений. Сегодня Microsoft последовательно выносит всё больше работы из runtime в этап компиляции: JSON‑сериализация, логирование, регулярные выражения, конфигурация и даже тестовые фреймворки всё чаще опираются на source generators.
Разбираемся, почему рефлексия начала сдавать позиции, где кодогенерация уже стала стандартом и что это меняет для разработчиков.NET.
В C++ часть ошибок выглядит слишком безобидно, чтобы сразу насторожиться: std::move в return, emplace_back «для скорости», перемещение из const, move‑конструктор без noexcept. Код компилируется, тесты могут проходить, а потом внезапно появляются лишние копирования, просадки производительности и странное поведение объектов.
Разберём пять типичных ловушек move‑семантики на небольших задачах и посмотрим, где именно ожидания разработчика расходятся с тем, что реально делает язык.
Принято считать, что для анализа макроэкономики и прогнозирования ВВП необходимы мощные серверы. Обычно разработчики используют Python и тяжелые библиотеки вроде TensorFlow или PyTorch. Однако бывают случаи когда надо чтобы модель была доступна на обычно ноутбуке или мы хотим применить наработки модели и переложить их на платы ардуино с лимитом памяти 32 кб и ценой в розничном магазине 300 - 400 рублей за штуку?
Решением проблемы становится полный отказ от сторонних фреймворков. Вся математика нейронных слоев написана с нуля на чистом C++20, а для быстрого подбора весов на ПК применяется технология NVIDIA CUDA. Сама модель имитирует реальные циклы оборота капитала. Четыре скрытых слоя нелинейной сети сжимаются до шести проекционных нейронов по методологии Всемирного банка.
Вообще идея применять нейронные сети для предсказания экономических процессов зародилась в конце XX века. Ученые искали замену обычным линейным моделям. Одними из первых нелинейные свойства ИНС для макроэкономических рядов США исследовали N. R. Swanson и H. White [2]. Они доказали, что гибкие связи лучше находят скрытые циклы.C.-M. Kuan и T. Liu [4] выявили, что очистка данных перед подачей в сеть сильно снижает ошибку. В начале 2000-х годов началось активное сравнение нейронных сетей с классическими методами вроде ARIMA. M. Marcellino [5], K. Neusser и M. Wagner [9] доказали превосходство многослойных сетей при анализе ВВП европейских стран на длинных дистанциях, а переключение весов C.-M. Lin и P.-H. Chen [7] помогает предсказывать кризисные периоды. Современный этап связан с обработкой больших массивов информации. В Индии S. Ghosh [6], M. C. Medeiros с соавторами [8] успешно применили нейросети для поиска скрытых зависимостей в индийской экономике.Q. Zhang и Y. Bian [3] в 2024 году провели масштабные тесты по отслеживанию темпов роста китайского ВВП. Они подтвердили преимущество нелинейных функций активации.
Надеюсь, вам понравилась статья про работу с памятью на консолях, где каждый ездил на том велосипеде, который сам же и придумал, попробую рассказать про зоопарк теперь уже стандартных библиотек. Стандартных в отдельной студии или конторе, потому что у соседней будет свой стандартный стандарт. Забавно что любовь прикрутить очередную погремушку к своему велосипеду становится тем сильнее, чем становится крупнее контора, поэтому приходя в игровую студию есть очень немаленький шанс, что стандартный STL у неё нестандартный, обёрнут или вовсе запрещён религией кодстайлом.
EA, Facebook, Google, Adobe, LLVM и рядок компаний поменьше тратят человеко-десятилетия в поисках ответа на главый вопрос жизни, Вселенной и всего такого «почему std:: это медленно, непредсказуемо и жрёт память». По аналогии с прошлой статьей вам не потребуется знать стандарт наизусть, а будет достаточно понимать, что такое указатель, чем вектор отличается от дерева и почему промах в кеше это дорого, а дальше я пройдусь по разным стандартным библиотекам и про каждую немного расскажу, что это, зачем оно появилось и где об него можно больно удариться, потому что про вот этот последний пункт обычно забывают "продаваны" и прочие студийные еванглелисты, когда расказывают какое там всё красивое, легкое и с++двадцатое.
Лямбды в C++ выглядят безобидно, пока не начинают жить дольше переменных, которые захватили. Висячие ссылки, мёртвый this, копии состояния в потоках и ограничения std::function часто проходят компиляцию без шума, зато потом превращаются в undefined behavior.
Разбираем пять задач на захваты и время жизни, где ошибка прячется не в синтаксисе, а в неверном предположении о том, кому и сколько живёт объект.
Двоичный интерфейс приложений, чаще именуемый просто ABI — это концепция, которая кажется знакомой и незнакомой одновременно. В каком смысле знакомой? Об ABI часто говорят в контексте устранения неисправностей, упоминают в статьях. Иногда даже приходится решать проблемы с совместимостью, которые провоцирует этот интерфейс. А в каком смысле незнакомый? Дело в том, что, если кто-то попросит вас описать, что такое ABI — то вы обнаружите, что понимаете, о чём речь, но чётко сформулировать ответ на этот вопрос сложновато. В конце концов, можно ограничиться формулировкой, указанной в Википедии: «набор соглашений для доступа приложения к операционной системе и другим низкоуровневым сервисам, спроектированный для переносимости исполняемого кода между машинами, имеющими совместимые ABI». Возникает ли проблема с такой формулировкой? Нет, в качестве общего описания этого вполне достаточно. Но оно может казаться немного поверхностным.
На самом деле, в информатике такая ситуация встречается нередко. Информатика — это дисциплина, не стремящаяся к абсолютной строгости. У многих концепций нет чёткого определения, зачастую бывает достаточно, чтобы описываемый феномен был общепонятным. Итак, чтобы не увязнуть в определениях, давайте рассмотрим, что именно представляют собой такие двоичные интерфейсы, и какие факторы влияют на их стабильность.
13 июня закончилась встреча комитета по стандартизации C++ (также известного как WG21) в Брно (Чехия), на которой комитет работал над будущим стандартом C++, C++29. В этой статье кратко пересказаны все принятые в него нововведения с примерами их использования и ссылками на оригинальные пропозалы для тех, кто захочет познакомиться с ними детально.
Недавно передо мной встала задача расчетной гидро-газо динамики, надо было посчитать сопротивление воздуха, форму огибающего потока, все то, что требовалось, чтобы посчитать траекторию летящего тела. В этой статье я подробно написал и объяснил, как создать CFD solver.
Есть такая забавная категория людей в разработке, давайте назовём их IT-волки. Это те самые ребята, у которых в 26 лет уже 12 лет опыта, в 27 два проекта и архитектура уровня «я тут всё с нуля поднял», а в 28 управление двумя командами под миллион MAU.
Иногда смотришь такое CV и думаешь - ну всё, сейчас придёт человек, который видел боль, огонь и сломаный прод, а потом начинается интервью. И очень быстро становится понятно, что дело вообще не в синтаксисе или знаниях фреймворков, иногда это могут быть идеальные знания, что тоже пугает. Знания конкретных фреймворков, это вообще не проблема и можно забыть название паттерна, потому что этих самых паттернов овердофига и можно перепутать детали. Это нормально, у всех бывает, интереснее другое. Когда начинаешь спрашивать про реальные решения, про ошибки, про “что вы делали”, про “почему вы это сделали именно так”... вот тут часто начинается тишина.
В современном UI помимо удобства есть еще свистелки и гуделки, чтобы зацепить взгляд пользователя. И, зачастую, такой свистелкой являются анимации: нажал кнопку, а у тебя вокруг спец-эффекты, поставил палец вверх, а он красиво подпрыгнул, и так далее.
Большинство таких анимаций, которые вы видите в приложениях практически каждый день, сделаны с помощью Lottie. Например, тут, в Telegram, часть анимированных стикеров и эмодзи сделаны как раз с помощью Lottie.
Почему именно Lottie? Lottie — это JSON-based формат векторной анимации, поэтому он легковесный, легко масштабируется, не требует видеокодеков, хорошо выглядит на экранах с разным DPI.
Привет, Хабр! Меня зовут Кирилл, я разработчик СХД в YADRO и ML-энтузиаст, автор книги "Hands-on Machine Learning with C++". Я заметил, что роль С/С++ в экосистеме машинного обучения трансформируется прямо сейчас. Чтобы понять, какое значение язык играет в развитии ML, мы поговорим о классическом применении C++ для ручной оптимизации вычислительных ядер. Затем разберемся, почему новый стандарт не закрепляет реализаций линейной алгебры, а отдает это на откуп поставщикам стандартной библиотеки и вендорам оборудования. И в завершение подумаем, как работать с «зоопарком реализаций», который из-за этого остается.
Исполним обещанное в [1], где упомянута задача о светофоре Ангера [2]. Она интересна формулировкой, которая заметно отличается от аналогичных задач, и утверждением, что более компактного решения, чем предложенное автором монографии, не существует.
Обычно светофоры моргают, «тупо» реализуя фиксированную временную последовательность. В светофоре С..Ангера есть динамизм. Он определяется датчиками, фиксирующими ситуацию на перекрестке. И это само по себе интересно. А утверждение формальным путем, сомневаться в справедливости которого оснований, казалось бы, нет.
Но нет исследователя, который не ставил бы перед собой задачу доказать недоказуемое или опровергнуть неопровергаемое. И один из способов достичь желаемого – создать решение, подтверждающее вашу правоту. Как настоящие исследователи, мы именно это и попытаемся сделать, опровергнув, если удастся, тем самым утверждение С.Ангера.
А начнем мы с реализации светофора в исходной формулировке, хотя и в рамках другой формальной модели [3].
Продолжение. Начало здесь. Предыдущая часть. Репозиторий с кодом - на гитхабе.
(Сокращения: НАМ - нормальные алгорифмы Маркова, КТ - компайл-тайм, РТ - рантайм).
Следующая неприятность, которая нас ждёт, - это циклы, которые в КТ вовсе не циклы. Нам надо как-то научиться бегать по правилам, из которых состоит НАМ-программа.
Это вторая статья об использовании LLM в проекте разработки компилятора языка программирования как транспилятора в код на C++. Я продолжаю историю и хочу рассказать о своих наблюдениях и впечатлениях от попыток применять автономных агентов в большом и сложном проекте. А также о навязчивой рекламе и встроенных «закладках» в коде некоторых инструментов, которые, похоже, целенаправленно ухудшают работу с моделями конкурентов.
Новая графическая эпоха для игры детства , реалистичный туман , оптимазиация , кроспалтформеность и современые тени
Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.
Привыкаешь к этому быстро. Нам кажется совершенно естественным тасовать эти типы между собой – уж слишком давно так делается по всей индустрии. Но стоит лишь чуток задуматься, и начинает прорезаться легкий когнитивный диссонанс: выходит, вся наша графика построена на наборах несовместимых между собой математических запчастей. Для одного действия нам нужен один тип данных, для второго – другой, а пересчитать простое столкновение луча со сферой или плоскостью без пятого велосипеда никак не получается. Вроде бы всё работает и даже неплохо работает… Но ощущение конструктора из костылей не отпускает.
И самое интересное заключается в том, что так было не обязательно.
Привет, мой читатель с Хабра!
Знаешь ли ты о том, что такое многопоточное программирование? Если да, то это хорошо! Если же нет, то придётся почитать немного скучноватой теории про такую известную технологию программирования, как многопоточное программирование, а затем мы копнём эту тему глубже…
