Библиотека С# С++

⚡️ Machine Learning Roadmap 2025: большая карта входа в ML без сказок про “нейросети за месяц Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps и даже вабкодинга. Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и что должно получиться на практике после каждого этапа. Roadmap разбит на 7 треков: 1. Фундамент: Python, математика, статистика, инструменты 2. Классический ML: scikit-learn, табличные данные, метрики, валидация 3. Deep Learning: PyTorch, CNN, RNN, training loop 4. LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты 5. Generative AI: изображения, видео, аудио, мультимодальность 6. MLOps и прод: Docker, Kubernetes, CI/CD, monitoring, serving 7. Специализация: CV, NLP, RecSys, RL, Safety Roadmap не продаёт иллюзию “обучил модель - стал ML-инженером”. В реальной работе много времени уходит на данные, метрики, деплой, мониторинг, воспроизводимость и разбор ошибок. Модель - только часть системы. Хорошая мысль из roadmap: LLM не делает джуна сеньором. Она ускоряет того, кто уже понимает базу. Без базы человек просто становится оператором Copilot, который не может объяснить, почему всё сломалось. По времени тоже без сказок: 1. 0-3 месяца: Python, математика, классический ML 2. 3-6 месяцев: Deep Learning и PyTorch 3. 6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты 4. 12+ месяцев: MLOps, прод, масштабирование, специализация Тут же собрано 7 болших бесплатных курсов по машинному обучению, математике и вайбкодингу! Если давно хотели зайти в ML системно, а не прыгать между роликами про ChatGPT, Stable Diffusion и “топ-10 библиотек”, это хороший ориентир. https://github.com/justxor/MachineLearningRoadmap

C умел «объектный стиль» задолго до модных споров про ООП. В Linux-драйверах это видно особенно хорошо. Каждый драйвер фактически реализует интерфейс, просто заполняя структуру с указателями на функции. file_operations из include/linux/fs.h - хороший пример. Ядро говорит: вот набор операций, которые может поддерживать файл, сокет или устройство. Драйвер сам решает, какие обработчики дать: open read write release mmap fsync unlocked_ioctl Если операция не нужна, поле остаётся NULL, и ядро использует поведение по умолчанию там, где это возможно. По сути это тот же контракт между системой и реализацией, только без классов, наследования и рантаймовой магии. Есть таблица функций, есть объект, есть набор действий, которые с ним можно выполнить. Именно поэтому C до сих пор живёт в ядрах, драйверах и системном коде. Он не навязывает модель абстракций, но даёт достаточно низкоуровневых инструментов, чтобы собрать нужную модель самому. Просто вместо красивого слова interface у тебя struct с function pointers. #programming #linux #c

C++23 добавил `std::expected`, и это одна из самых практичных вещей в языке за последние годы. Идея простая: функция возвращает либо нормальный результат, либо ошибку. Без исключений, без output-параметров и без неявного control flow, который потом сложно отследить. Например, парсер заголовка может вернуть uint32_t, если всё хорошо, или std::error_code, если буфер слишком короткий. Вызывающая сторона сразу видит: здесь результат может быть ошибкой, её нельзя «случайно забыть» так же легко, как при старом стиле с кодами возврата. Это особенно удобно для системного кода, сетевых протоколов, парсеров, embedded и всего, где исключения либо запрещены, либо нежелательны. std::expected не делает обработку ошибок магической. Он просто заставляет контракт функции быть честным: успешный результат и возможная ошибка описаны прямо в типе.

⚡️ Fenwick Tree держится на одном битовом трюке Fenwick Tree, или Binary Indexed Tree, считает prefix sums за O(log n). Вся магия в операции: i & -i Она находит младший установленный бит числа. Почему это работает? В two’s complement число -i получается как инверсия битов i плюс 1. Когда мы делаем i & -i, остаётся только самый правый бит, равный 1. Например: i = 12 // 1100 -i // 0100 в нужной маске i & -i = 4 Именно это значение говорит Fenwick Tree, на сколько нужно прыгнуть по индексам. Для обновления: for (; i < MAXN; i += i & -i) tree[i] += v; Мы идём вверх по структуре и обновляем все узлы, которые покрывают этот индекс. Для запроса суммы: for (; i > 0; i -= i & -i) s += tree[i]; Мы идём вниз и собираем нужные блоки суммы. Одна и та же операция управляет двумя направлениями: * i += i & -i — перейти к следующему ответственному узлу * i -= i & -i — убрать последний блок из prefix sum Поэтому Fenwick Tree такой компактный: никаких явных рёбер, указателей и рекурсии. Только массив и битовая арифметика. Красота структуры в том, что дерево как бы спрятано внутри двоичного представления индекса.

Аллокации, которых нет в коде: охота на скрытый боксинг в .NET 10 Самая дорогая аллокация в вашем сервисе та, которой нет в исходниках. Вы написали struct ради zero-allocation, прошли code review, а в проде Gen0-коллекции все равно идут косяком. Потому что между вашим кодом и машинным кодом стоит компилятор, и он молча упаковывает ваш value-тип в кучу там, где вы этого не просили — а на код-ревью этого не видно. TL;DR. Боксинг (boxing) в .NET - это не только object o = 42. Он прячется в вызовах интерфейсных методов на struct, в дефолтном ValueType.Equals, в params object[]-аргументах, в foreach по интерфейсу и в замыканиях. При этом часть “классических” примеров боксинга из старых гайдов на современном рантайме уже не аллоцирует — JIT научился их вырезать, и слепо копировать советы десятилетней давности вредно. Ниже — карта мест, где боксинг живёт и сейчас, отдельный разбор того, что рантайм уже оптимизировал, реальный мини-кейс, воспроизводимый бенчмарк на BenchmarkDotNet с MemoryDiagnoser, способ ловить упаковку через DOTNET_JitDisasm и dotnet-gcdump, и паттерны лечения без потери читаемости. О версиях и числах. Всё прверялось на .NET 10 (текущий LTS) и C# 13/14-уровне компилятора, Release, без отладчика, BenchmarkDotNet с MemoryDiagnoser. На .NET 8/9 поведение в основном такое же, но отдельные оптимизации JIT отличаются между мажорными версиями — поэтому главный принцип статьи: не верьте на слово (в том числе мне), гоняйте MemoryDiagnoser на своей версии рантайма. Числа в таблицах ниже - иллюстративные, порядок величины, а не точные замеры с вашего железа. Пролог: “у нас же всё на struct, откуда Gen0?” Сервис на горячем пути считает метрики: миллионы маленьких readonly struct-значений в секунду, никакого new, никаких классов в hot path. По задумке — ноль аллокаций. На дашборде — стабильный поток Gen0-коллекций раз в несколько секунд под нагрузкой. Профайлер показывает аллокации, но стек ведёт в метод, где в коде нет ни одного new. Там цикл по интерфейсу, пар

Красота C в том, что он почти не прячет механику компьютера. Хочешь понять, как копируется файл? Не нужен огромный фреймворк. Достаточно посмотреть на простой C-код: • открыть исходный файл через fopen • открыть файл назначения • выделить буфер через malloc • читать кусками через fread • записывать через fwrite • освободить память и закрыть файлы Всё честно и прямо: байты читаются из одного места и записываются в другое. Именно поэтому C до сих пор так важен. Он не всегда самый удобный, но он показывает, что реально происходит под капотом. После такого начинаешь лучше понимать не только язык, а саму систему.

🗺️ Полный роадмап C++ 2026 — от нуля до профессионала Это не просто список тем, а пошаговый маршрут превращения новичка в профессионального C++-разработчика. Каждый уровень даёт не только перечень концепций, но и рабочие примеры кода с пояснениями «как правильно» и «как неправильно», чтобы вы сразу видели идиоматичный современный C++, а не устаревшие практики из учебников 2000-х годов. Роадмап построен по принципу «теория рядом с практикой»: сначала вы изучаете концепцию на коде из соответствующего уровня, а затем углубляете понимание в разделе. 📚 Теория C++, где каждая тема разобрана от базовой интуиции до тонкостей, важных на собеседованиях и в продакшене. Такой подход экономит месяцы: вы не зубрите оторванные факты, а понимаете, почему язык устроен именно так. Как пользоваться: идите по уровням сверху вниз, не перепрыгивая. Пишите каждый пример руками, ломайте его, смотрите на ошибки компилятора — именно так формируется интуиция. Параллельно решайте задачи на платформах из раздела ресурсов и читайте теорию по мере появления вопросов. https://github.com/justxor/cpproadmap2026/tree/main

## C++ enum class: безопасно, но местами раздражает enum class даёт строгую типизацию и не позволяет случайно смешивать значения с обычными числами. Но есть нюанс: даже если enum используется как набор флагов, Flags::Read | Flags::Write не скомпилируется. Для |, &, ^, ~ придётся вручную определить операторы и приводить значения к базовому типу. Это правильное поведение с точки зрения type safety, но бойлерплейта становится заметно больше. Поэтому в некоторых C++-проектах для битовых флагов до сих пор используют обычный enum внутри namespace: меньше защиты, зато код значительно проще.

Четыре строки делают сложение `float` заметно точнее При последовательном сложении чисел с плавающей точкой часть младших битов теряется из-за округления. На больших массивах эта ошибка постепенно накапливается. Алгоритм Кэхэна хранит потерянную часть в отдельной переменной и компенсирует её на следующем шаге: float kahanSum(const float *nums, int count) { float sum = 0.0f; float correction = 0.0f; for (int i = 0; i < count; ++i) { float adjusted = nums[i] - correction; float next = sum + adjusted; correction = (next - sum) - adjusted; sum = next; } return sum; } Здесь correction запоминает ошибку округления, которая потерялась при предыдущем сложении. Обычная сумма быстрее, но Kahan Summation полезен там, где важна численная точность: - научные расчёты; - статистика и аналитика; - графика и симуляции; - обработка больших массивов; - накопление очень маленьких значений рядом с большими. Метод предложил Уильям Кэхэн в 1965 году. Небольшое усложнение цикла может заметно уменьшить ошибку без перехода на более тяжёлый числовой тип.

🧠 Алгоритм, который превращает выражение в форму, где приоритеты операторов больше не нужны Алгоритм сортировочной станции Дейкстры получил название в честь железнодорожной сортировочной станции - и работает очень похоже. Он преобразует обычную инфиксную запись: 3 + 4 * 2 в постфиксную: 3 4 2 * + После этого калькулятору уже не нужно каждый раз разбираться с приоритетами операторов и строить полноценное AST. Как работает идея: - один стек хранит операторы; - второй поток формирует результат; - операторы с более высоким приоритетом выходят раньше; - скобки и ассоциативность обрабатываются по правилам стека. В итоге выражение можно вычислять последовательно и без рекурсивного спуска. Простой, старый и до сих пор очень красивый алгоритм для парсеров, калькуляторов и компиляторов. #Algorithms #C #Programming #Compilers #ComputerScience

🖥 C++: объект уничтожен, а 16 МиБ всё ещё заняты std::weak_ptr может удерживать память даже при expired() == true. Причина в std::make_shared: обычно он размещает объект и управляющий блок в одной аллокации. В примере на скриншоте массив на 16 МиБ находится прямо внутри Blob. После удаления последнего shared_ptr: * деструктор объекта вызывается; * expired() возвращает true; * общий блок памяти остаётся выделенным, пока существует хотя бы один weak_ptr. После сброса последней слабой ссылки блок можно освободить. Что делать: удалять протухшие ссылки из долгоживущих кешей. Для крупных объектов также можно рассмотреть отдельную аллокацию через std::shared_ptr<Blob>(new Blob()). Нюанс касается размера самого объекта. Если данные хранятся в обычном std::vector, его отдельный буфер освобождается при вызове деструктора. [Разбор от Microsoft](https://devblogs.microsoft.com/oldnewthing/20230815-00/?p=108602)

Rust vs Go vs C# в 2026: почему наивный Rust проиграл Go Сравнение производительности Rust, Go и C# в 2026 году: наш тест на аллокациях, где наивный Rust уступил Go, а Rust с ареной оказался в 7 раз быстрее, плюс разбор GC, памяти, холодного старта, Green Tea и .NET 10 Спор «что быстрее: Rust, Go или C#» обычно заканчивается ссылкой на чей-то бенчмарк, где один язык обгоняет другой в полтора раза. Мы решили проверить простую вещь и сразу получили результат, который ломает привычную картину: наивный код на Rust проиграл Go по времени выполнения. Ниже разбираем, почему так вышло, что на самом деле означает «производительность» в 2026 году и как выбирать язык под конкретную нагрузку. https://uproger.com/rust-vs-go-vs-csharp-proizvoditelnost-2026/