🖥️ Вышел FEX 2508 — новый эмулятор x86 для ARM-чипов. Проект FEX представил обновлённую версию эмулятора, который позволяет запускать x86-приложения и игры на устройствах с ARM64, включая Mac на Apple Silicon. Технология использует JIT-компиляцию и overlay-образы rootfs для совместимости без полного chroot.
В этом релизе — серьёзный прирост производительности: например, Cyberpunk 2077 теперь работает на 38,9% быстрее. Также добавлена поддержка NX-бита и улучшена защита от отладки для некоторых игр.
🔗 Ссылка - *клик*
В этом релизе — серьёзный прирост производительности: например, Cyberpunk 2077 теперь работает на 38,9% быстрее. Также добавлена поддержка NX-бита и улучшена защита от отладки для некоторых игр.
🔗 Ссылка - *клик*
❤3👍3
🔝 В полезную коллекцию добавляем бесплатный курс по современному C++
Углублённое обучение, состоящее из 28 тематических блоков — от базовых концепций до продвинутых приёмов. Материал структурирован от простого к сложному (пример — на скрине).
https://www.learncpp.com/
Углублённое обучение, состоящее из 28 тематических блоков — от базовых концепций до продвинутых приёмов. Материал структурирован от простого к сложному (пример — на скрине).
https://www.learncpp.com/
❤4🔥4👍1
@cpluscsharp
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
Media is too big
VIEW IN TELEGRAM
Метод преодоления "барьера сортировки" для задач кратчайшего пути в ориентированных графах.
Группа исследователей из университетов Синьхуа, Стенфорда и Института Макса Планика представили детерминированный алгоритм для решения задачи SSSP в ориентированных графах с неотрицательными вещественными весами, который работает за время, пропорциональное числу ребер, умноженному на логарифмический множитель, который растет медленнее, чем обычный логарифм.
Проблема поиска кратчайшего пути от одной вершины до всех остальных (SSSP) — одна из фундаментальных в теории графов, и её история тянется с 50-х годов прошлого века. Классический алгоритм Дейкстры, в связке с продвинутыми структурами данных, решает эту задачу за время, которое примерно пропорционально сумме числа рёбер и произведения числа вершин на логарифм от их же числа.
Именно этот множитель - число вершин, умноженное на логарифм, долгое время считался теоретическим минимумом, так как в своей основе алгоритм Дейкстры побочно сортирует вершины по расстоянию от источника. Этот предел известен как «барьер сортировки» и казался непреодолимым.
Алгоритм Дейкстры на каждом шаге выбирает из "границы" - множества еще не обработанных вершин ту, что находится ближе всего к источнику. Это и создает узкое место, так как размер границы может достигать величины, сопоставимой с общим числом вершин в графе, и на каждом шаге требуется находить минимум.
Алгоритм Беллмана-Форда, в свою очередь, не требует сортировки, но его сложность пропорциональна числу ребер, умноженному на количество шагов, что слишком долго.
Вместо того чтобы поддерживать полную отсортированную границу, алгоритм фокусируется на ее сокращении. А если граница слишком велика, то запускается несколько шагов алгоритма Беллмана-Форда из ее вершин.
Это позволяет найти точное расстояние до некоторой части вершин, чьи кратчайшие пути коротки. Длинные же пути должны проходить через одну из "опорных" вершин, которых оказывается значительно меньше, чем вершин в исходной границе. Таким образом, сложная работа концентрируется только на этом небольшом наборе опорных точек.
Он рекурсивно разбивает задачу на несколько уровней. На каждом уровне применяется вышеописанная техника сокращения границы, что позволяет значительно уменьшить объем работы на каждую вершину, поскольку логарифмический множитель эффективно делится на другой, более медленно растущий логарифмический член.
В итоге, путем подбора внутренних параметров алгоритма, которые являются специфическими функциями от логарифма числа вершин, и достигается итоговая временная сложность, пропорциональная числу ребер, умноженному на этот новый, более медленно растущий логарифмический множитель.
— Быстрее решаются задачи в навигации, графах дорог, сетях и планировании.
— Доказано, что Дейкстра — не предел, и можно ещё ускорять поиск кратчайших путей.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍4
🎮 Погружаемся в SQL, с помощью увлекательной аркадной игры
Разработчики замутили настоящий олдскульный шедевр, который сделает из вас МАСТЕРА баз данных и точно не даст заскучать.
• Проходим уровни, собираем пазлы вместе с уткой DuckDB и прокачиваем SQL на максимум.
• Квесты, задачи, подсказки — всё как в настоящем приключении.
• Работает прямо в браузере и даже на телефоне.
Любые запросы к базам — щёлкаем как семечки 👉 https://dbquacks.com/.
Разработчики замутили настоящий олдскульный шедевр, который сделает из вас МАСТЕРА баз данных и точно не даст заскучать.
• Проходим уровни, собираем пазлы вместе с уткой DuckDB и прокачиваем SQL на максимум.
• Квесты, задачи, подсказки — всё как в настоящем приключении.
• Работает прямо в браузере и даже на телефоне.
Любые запросы к базам — щёлкаем как семечки 👉 https://dbquacks.com/.
👍3❤2🗿1
🔥 Хотите разобраться в ASP.NET Core на практике?
Репозиторий — это более 400+ римеров для всех версий ASP.NET Core (от 2.1 до 10 Preview).
Что внутри:
- Minimal API, Blazor, SignalR, gRPC
- Аутентификация, кэширование, health-checks
- Middleware, Razor Pages, HTMX и многое другое
Каждый пример запускается командой
⭐ Репо собрало уже 10k+ звёзд и считается одним из лучших ресурсов для изучения ASP.NET Core.
📌 Github
Репозиторий — это более 400+ римеров для всех версий ASP.NET Core (от 2.1 до 10 Preview).
Что внутри:
- Minimal API, Blazor, SignalR, gRPC
- Аутентификация, кэширование, health-checks
- Middleware, Razor Pages, HTMX и многое другое
Каждый пример запускается командой
dotnet watch run и демонстрирует отдельную фичу. ⭐ Репо собрало уже 10k+ звёзд и считается одним из лучших ресурсов для изучения ASP.NET Core.
📌 Github
❤5🔥3👍1🥰1🥱1👀1
Forwarded from DevOps
Какой язык программирования имеет самый запутанный код? 🤔
Команда TIOBE проанализировала более 8 000 коммерческих проектов и 1,5 млрд строк кода, чтобы выяснить, где цикломатическая сложность (количество возможных путей выполнения функции) выше всего.
📊 Вот результаты:
1️⃣ MATLAB (6.03 пути/функция) — часто используется учёными и инженерами-доменщиками, а не разработчиками, поэтому код выходит менее структурированным.
2️⃣ C (5.74) — ручная обработка ошибок → множество
3️⃣ JavaScript (3.50) — быстрая разработка, постоянно меняющиеся требования и разный уровень фронтенд-разработчиков.
4️⃣ Go (3.39) — идиоматический паттерн обработки ошибок с множеством явных проверок.
5️⃣ Python (2.71) и TypeScript (2.51) — средняя сложность, отражающая гибкий синтаксис и широкий спектр применения.
6️⃣ C++ (2.45), Java (2.24), C# (2.08) — сравнительно ниже благодаря зрелым фичам и структурированным практикам.
7️⃣ Rust (1.32) — самая низкая сложность, подчёркивающая потенциал безопасных и простых решений.
📝 Итог: на сложность влияет не только сам язык, но и опыт разработчиков, культура кодинга и подходы к обработке ошибок.
📌 Подробности
#программирование #разработка #код #softwareengineering
Команда TIOBE проанализировала более 8 000 коммерческих проектов и 1,5 млрд строк кода, чтобы выяснить, где цикломатическая сложность (количество возможных путей выполнения функции) выше всего.
📊 Вот результаты:
1️⃣ MATLAB (6.03 пути/функция) — часто используется учёными и инженерами-доменщиками, а не разработчиками, поэтому код выходит менее структурированным.
2️⃣ C (5.74) — ручная обработка ошибок → множество
if/else и условий. 3️⃣ JavaScript (3.50) — быстрая разработка, постоянно меняющиеся требования и разный уровень фронтенд-разработчиков.
4️⃣ Go (3.39) — идиоматический паттерн обработки ошибок с множеством явных проверок.
5️⃣ Python (2.71) и TypeScript (2.51) — средняя сложность, отражающая гибкий синтаксис и широкий спектр применения.
6️⃣ C++ (2.45), Java (2.24), C# (2.08) — сравнительно ниже благодаря зрелым фичам и структурированным практикам.
7️⃣ Rust (1.32) — самая низкая сложность, подчёркивающая потенциал безопасных и простых решений.
📝 Итог: на сложность влияет не только сам язык, но и опыт разработчиков, культура кодинга и подходы к обработке ошибок.
📌 Подробности
#программирование #разработка #код #softwareengineering
❤7
уникальных идентификаторов
Многие разработчики используют UUID (или Guid в C#) как уникальные ключи в базе данных.
📌 Проблема старых UUID:
- 🔀 они «случайные» — удобно для распределённых систем, но…
- 🧱 занимают 16 байт → таблицы и индексы раздуваются
- 📉 вызывают фрагментацию индексов, ведь данные неупорядоченные
⚡ Решение — UUID V7
- содержит компонент времени, поэтому значения сортируются
- 👉 работает быстрее с индексами
- 🔧 в .NET 9 можно создать через Guid.CreateVersion7()
- 🐘 поддержка появится в Postgres 18
Вопрос: а вы бы стали использовать UUID V7 в своих проектах?
#dotnet #postgres #uuid #database
Многие разработчики используют UUID (или Guid в C#) как уникальные ключи в базе данных.
📌 Проблема старых UUID:
- 🔀 они «случайные» — удобно для распределённых систем, но…
- 🧱 занимают 16 байт → таблицы и индексы раздуваются
- 📉 вызывают фрагментацию индексов, ведь данные неупорядоченные
⚡ Решение — UUID V7
- содержит компонент времени, поэтому значения сортируются
- 👉 работает быстрее с индексами
- 🔧 в .NET 9 можно создать через Guid.CreateVersion7()
- 🐘 поддержка появится в Postgres 18
Вопрос: а вы бы стали использовать UUID V7 в своих проектах?
#dotnet #postgres #uuid #database
👍13❤3🤯1
This media is not supported in your browser
VIEW IN TELEGRAM
🧠 Инструмент визуализации памяти для C++
MV — это инструмент для реального времени, который помогает понять управление памятью в C++. Он визуализирует стек и кучу, что делает его идеальным для изучения таких концепций, как указатели, утечки памяти и управление кучей.
🚀 Основные моменты:
- Визуализация работы указателей и ссылок
- Понимание различий между стеком и кучей
- Выявление и анализ утечек памяти
- Поддержка базовых концепций C++
📌 GitHub: https://github.com/humblepenguinn/mv
#cpp
MV — это инструмент для реального времени, который помогает понять управление памятью в C++. Он визуализирует стек и кучу, что делает его идеальным для изучения таких концепций, как указатели, утечки памяти и управление кучей.
🚀 Основные моменты:
- Визуализация работы указателей и ссылок
- Понимание различий между стеком и кучей
- Выявление и анализ утечек памяти
- Поддержка базовых концепций C++
📌 GitHub: https://github.com/humblepenguinn/mv
#cpp
❤3👍2
Подход к реализации постоянных параметров шаблонов через библиотеку
Этот блогпост стал продолжением моей работы с Ричардом Смитом (P2484), за которым последовала ещё одна статья по теме (P3380). И статья, и доклад основывались на блестящей идее Файсала Вали: рефлексия может предложить интересное решение задачи сериализации, ведь
На встрече в Софии все документы, касающиеся рефлексии, были включены в рабочий проект стандарта C++26, и для меня это очень воодушевляюще — видеть формулировки прямо в черновике (например, meta.reflection).
Однако моё решение по расширению поддержки постоянных параметров шаблонов в C++26 не войдёт. Как и решение проблемы non-transient constexpr allocation. Так что ограничения на типы, которые можно использовать в качестве постоянных параметров шаблонов, сохранятся ещё на один цикл.
А может… и нет?
https://brevzin.github.io/c++/2025/08/02/ctp-reflection/
#cpp #programming
Ранее эти параметры шаблонов назывались нетиповыми параметрами шаблонов (non-type template parameters). Но с момента появления C++98 у нас всегда было три вида параметров шаблонов:
- типовые параметры (type template parameters)
- нетиповые параметры (non-type template parameters)
- шаблонные параметры-шаблоны (template template parameters)
Когда категорий всего две, можно называть их «X» и «не-X» (например, статические и нестатические методы). Но когда категорий три — это уже неудобно. А в C++26 таких категорий уже пять (добавились параметры переменных шаблонов и параметры концептов), и выходит, что почти все, кроме типовых, попадают под «нетиповые» — что нелогично. Поэтому старый термин заменили на гораздо более удачный: constant template parameter (постоянный параметр шаблона).
Этот блогпост стал продолжением моей работы с Ричардом Смитом (P2484), за которым последовала ещё одна статья по теме (P3380). И статья, и доклад основывались на блестящей идее Файсала Вали: рефлексия может предложить интересное решение задачи сериализации, ведь
std::meta::info способен представлять что угодно.На встрече в Софии все документы, касающиеся рефлексии, были включены в рабочий проект стандарта C++26, и для меня это очень воодушевляюще — видеть формулировки прямо в черновике (например, meta.reflection).
Однако моё решение по расширению поддержки постоянных параметров шаблонов в C++26 не войдёт. Как и решение проблемы non-transient constexpr allocation. Так что ограничения на типы, которые можно использовать в качестве постоянных параметров шаблонов, сохранятся ещё на один цикл.
А может… и нет?
https://brevzin.github.io/c++/2025/08/02/ctp-reflection/
#cpp #programming
❤3🔥1
@cpluspluc
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
🏎️ Сравнение производительности C++20
ComPPare — это инструмент для бенчмаркинга и валидации производительности различных реализаций функций на C++20. Он позволяет сравнивать время выполнения и проверять результаты для разных платформ, таких как CPU, OpenMP и CUDA, что упрощает портирование функций.
🚀 Основные моменты:
- Заголовочный файл, легко интегрируется в проекты.
- Поддержка любых функций, работающих на хосте.
- Подробная информация о времени выполнения и накладных расходах.
- Встроенная проверка ошибок для распространенных типов данных.
📌 GitHub: https://github.com/funglf/ComPPare
#cpp
ComPPare — это инструмент для бенчмаркинга и валидации производительности различных реализаций функций на C++20. Он позволяет сравнивать время выполнения и проверять результаты для разных платформ, таких как CPU, OpenMP и CUDA, что упрощает портирование функций.
🚀 Основные моменты:
- Заголовочный файл, легко интегрируется в проекты.
- Поддержка любых функций, работающих на хосте.
- Подробная информация о времени выполнения и накладных расходах.
- Встроенная проверка ошибок для распространенных типов данных.
📌 GitHub: https://github.com/funglf/ComPPare
#cpp
GitHub
GitHub - funglf/ComPPare: Compare performance & correctness of reference vs. optimized functions (CPU, GPU, parallel). Written…
Compare performance & correctness of reference vs. optimized functions (CPU, GPU, parallel). Written in C++20. - funglf/ComPPare
🔥3👍1
Forwarded from C++ Academy
@cpluspluc
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥1
⚡ 📬 Как построить лёгкую in-memory шину сообщений на .NET Channels - отличный разбор.
В статье показано, как без внешних брокеров организовать событийную архитектуру внутри приложения, используя
🔗 Читать здесь: milanjovanovic.tech/blog/lightweight-in-memory-message-bus-using-dotnet-channels
#dotnet #csharp #architecture #messaging #inmemory```
В статье показано, как без внешних брокеров организовать событийную архитектуру внутри приложения, используя
System.Threading.Channels. Быстро, минималистично и эффективно. 🔗 Читать здесь: milanjovanovic.tech/blog/lightweight-in-memory-message-bus-using-dotnet-channels
#dotnet #csharp #architecture #messaging #inmemory```
❤3🔥1
И эти нестандартные проблемы требуют нестандартных решений.
Вот о таких решениях мы сегодня и поговорим.
А именно:
▪Посмотрим, как работают исключения на платформе Linux x86, и сделаем с ними что‑то интересное.
▪Залезем ещё глубже под капот исключений и сделаем их ещё быстрее.
▪Сделаем висячую ссылку на невалидный объект, и всё будет хорошо.
▪А под конец то, что все любим, — погрузимся в шаблонное метапрограммирование.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1
Прочитал у Вани Ходора, бэкендера из Лавки, пост про спекулятивное исполнение. Speculative execution — это мощный паттерн, где система предугадывает ваше следующее действие, заранее выполняя вычисления или подгружая данные.
В системном мире мы с этим живём постоянно. Процессоры уже десятилетиями предсказывают ветки кода, чтобы не простаивать. И именно поэтому они такие быстрые. Однако за эту высокую скорость пришлось платить — именно такой ценой появились уязвимости вроде Spectre. Даже железо может переусердствовать с догадками.
В прикладных системах то же самое:
спекуляция делает интерфейсы «мгновенными», но за кулисами идёт реальный перерасход. Предзагрузил слишком много — серверы греются, а пользователи даже не дошли до этой функции.
Я бы сказал так:
> спекулятивное исполнение — это ставка на интуицию машины.
> хорошо, когда она угадывает желания пользователя, плохо — когда начинает гадать.
В C++ подобные вещи ощущаются буквально: лишние вычисления, преждевременные аллокации, работа с кэшем — всё это цена «догадок». Если не знаешь, ради чего ускоряешь, то, скорее всего, просто сжигаешь ресурсы.
Speculative execution — крутой инструмент, но использовать его стоит только там, где задержка реально убивает UX или бизнес-метрику. В остальных случаях лучше просто сделать код лаконичным и быстрым.
В системном мире мы с этим живём постоянно. Процессоры уже десятилетиями предсказывают ветки кода, чтобы не простаивать. И именно поэтому они такие быстрые. Однако за эту высокую скорость пришлось платить — именно такой ценой появились уязвимости вроде Spectre. Даже железо может переусердствовать с догадками.
В прикладных системах то же самое:
спекуляция делает интерфейсы «мгновенными», но за кулисами идёт реальный перерасход. Предзагрузил слишком много — серверы греются, а пользователи даже не дошли до этой функции.
Я бы сказал так:
> спекулятивное исполнение — это ставка на интуицию машины.
> хорошо, когда она угадывает желания пользователя, плохо — когда начинает гадать.
В C++ подобные вещи ощущаются буквально: лишние вычисления, преждевременные аллокации, работа с кэшем — всё это цена «догадок». Если не знаешь, ради чего ускоряешь, то, скорее всего, просто сжигаешь ресурсы.
Speculative execution — крутой инструмент, но использовать его стоит только там, где задержка реально убивает UX или бизнес-метрику. В остальных случаях лучше просто сделать код лаконичным и быстрым.
Telegram
this->notes.
#highload
Есть такой паттерн speculative execution (⢄⠣⠌ ⠅⡠⢆⠒⢔⢄⢢⣀⠍ ⢃⠎⠚⡐⢰⡰⡰⡢⠲ ⢌⠥⠜⢅⠊⠃⡌⢈⡂⠰⡃ ⠡⡢ ⡅⠍ ⣄⡔⡘⡠⠉⠃⡆⢂⠓⠪⠩⢐⡠ ⡢⠩⢆⠱⠚⡡⢈⠦⡢⠕). Паттерн заключается в том, чтобы делать префетч данных ещё до того, как пользователь захочет что-то увидеть, чтобы в момент, когда он…
Есть такой паттерн speculative execution (⢄⠣⠌ ⠅⡠⢆⠒⢔⢄⢢⣀⠍ ⢃⠎⠚⡐⢰⡰⡰⡢⠲ ⢌⠥⠜⢅⠊⠃⡌⢈⡂⠰⡃ ⠡⡢ ⡅⠍ ⣄⡔⡘⡠⠉⠃⡆⢂⠓⠪⠩⢐⡠ ⡢⠩⢆⠱⠚⡡⢈⠦⡢⠕). Паттерн заключается в том, чтобы делать префетч данных ещё до того, как пользователь захочет что-то увидеть, чтобы в момент, когда он…
❤3
Forwarded from Machinelearning
Ошеломляющий контраст: одна NVIDIA ($4.6 трлн) сейчас стоит дороже, чем все банки США и Канады вместе ($4.2 трлн) 🫧
@ai_machinelearning_big_data
#nvidia
@ai_machinelearning_big_data
#nvidia
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤3🥰1
🧩 Почему Databento не переписали feed-handler на Rust
Кратко:
- Контекст: реальный поток 14 млн сообщений/с и задержки <100 мкс. Требовались native-язык, простая параллельность и минимум общей памяти.
- Итог: для переписывания feed-handler выбрали C++23, а не Rust — из-за нескольких «больно на практике» паттернов.
Где Rust мешал именно под их кейс:
1) Повторное использование буфера
Хотели выделять буфер вне цикла и переиспользовать на итерациях без копий. Ссылки + времена жизни → конфликт с borrow-checker, хотя логически данные не переживают итерацию.
2) Самоссылочные структуры (self-referential structs)
Базовый паттерн «владение состоянием в объекте + подкомпоненты держат ссылки» в Rust упирается в модель заимствования. Обходные пути — RC/Arc или протаскивать ссылки аргументами — добавляют оверхед/шум. В C++ — просто порядок полей и правила перемещения/копирования.
3) Компиляционные дженерики
Шаблоны C++ гибче (partial specialization, fold-expr, constexpr). В Rust те же идеи требуют trait-интерфейсов и шаблонного «лесовоздства». На десятках версий структур получается много шаблонного кода или макросов.
Нет, это не «Rust плох»:
- У Databento уже много Rust в проде: кодеки DBN, realtime-шлюзы, клиентская библиотека. Инструменты cargo, диагностика компилятора и безопасность — огромный плюс.
- Но под данный «узкий» участок C++ дал:
кодо-реюз со старой базы, тонкий контроль ресурсов, гибкие шаблоны и прямая экспертиза команды.
Вывод:
- В их финтех-стеке оба языка уместны: Rust — где важны безопасность и современная экосистема, C++ — где критичны сам паттерн владения/памяти и совместимость с существующим кодом. Поле меняется: C++ получает compile-time reflection, Rust развивает Polonius — решения всегда прагматичны под задачу.
https://databento.com/blog/why-we-didnt-rewrite-our-feed-handler-in-rust
Кратко:
- Контекст: реальный поток 14 млн сообщений/с и задержки <100 мкс. Требовались native-язык, простая параллельность и минимум общей памяти.
- Итог: для переписывания feed-handler выбрали C++23, а не Rust — из-за нескольких «больно на практике» паттернов.
Где Rust мешал именно под их кейс:
1) Повторное использование буфера
Хотели выделять буфер вне цикла и переиспользовать на итерациях без копий. Ссылки + времена жизни → конфликт с borrow-checker, хотя логически данные не переживают итерацию.
2) Самоссылочные структуры (self-referential structs)
Базовый паттерн «владение состоянием в объекте + подкомпоненты держат ссылки» в Rust упирается в модель заимствования. Обходные пути — RC/Arc или протаскивать ссылки аргументами — добавляют оверхед/шум. В C++ — просто порядок полей и правила перемещения/копирования.
3) Компиляционные дженерики
Шаблоны C++ гибче (partial specialization, fold-expr, constexpr). В Rust те же идеи требуют trait-интерфейсов и шаблонного «лесовоздства». На десятках версий структур получается много шаблонного кода или макросов.
Нет, это не «Rust плох»:
- У Databento уже много Rust в проде: кодеки DBN, realtime-шлюзы, клиентская библиотека. Инструменты cargo, диагностика компилятора и безопасность — огромный плюс.
- Но под данный «узкий» участок C++ дал:
кодо-реюз со старой базы, тонкий контроль ресурсов, гибкие шаблоны и прямая экспертиза команды.
Вывод:
- В их финтех-стеке оба языка уместны: Rust — где важны безопасность и современная экосистема, C++ — где критичны сам паттерн владения/памяти и совместимость с существующим кодом. Поле меняется: C++ получает compile-time reflection, Rust развивает Polonius — решения всегда прагматичны под задачу.
https://databento.com/blog/why-we-didnt-rewrite-our-feed-handler-in-rust
❤4
Forwarded from C++ Academy
🚀 Полное руководство по
Этот репозиторий предлагает точную конфигурацию для работы с
🚀 Основные моменты:
- Необходима установка
- Поддержка CMake 4.1+ для экспериментального импорта
- Точный UUID для включения модуля
- Полная поддержка C++23 обязательна
- Примеры проектов для быстрой настройки
📌 GitHub: https://github.com/JRASoftware/cpp23-import-std-guide
#cpp
import std; в C++23Этот репозиторий предлагает точную конфигурацию для работы с
import std; в GCC 15.1 и CMake 4.1. Сэкономьте время, следуя проверенным настройкам и избегая распространенных ошибок.🚀 Основные моменты:
- Необходима установка
CXX_MODULE_STD 1 для всех целей- Поддержка CMake 4.1+ для экспериментального импорта
- Точный UUID для включения модуля
- Полная поддержка C++23 обязательна
- Примеры проектов для быстрой настройки
📌 GitHub: https://github.com/JRASoftware/cpp23-import-std-guide
#cpp
GitHub
GitHub - JRASoftware/cpp23-import-std-guide: Complete guide for C++23 import std; with GCC 15.1 and CMake 4.1. Includes the critical…
Complete guide for C++23 import std; with GCC 15.1 and CMake 4.1. Includes the critical CXX_MODULE_STD property that most guides miss. - JRASoftware/cpp23-import-std-guide
❤2
Потрясающий C++
Это огромная подборка библиотек, фреймворков и ресурсов для C++. Всё собрано в одном месте и сгруппировано по категориям.
Сохраняйте в избранное, чтобы держать под рукой!
#cpp
Это огромная подборка библиотек, фреймворков и ресурсов для C++. Всё собрано в одном месте и сгруппировано по категориям.
Сохраняйте в избранное, чтобы держать под рукой!
#cpp
👍4❤2