Библиотека C/C++ разработчика | cpp, boost, qt

🎯 IT раскололся: почему у одних специалистов будущее, а у других — тупик

Рынок делится пополам: продуктовые компании забирают себе лучших людей, AI-инфраструктуру и все деньги. Остальным достается борьба за крохи с демпингом и выгоранием. Это уже происходит. Читай, пока есть время что-то изменить.

👉 Читать...

📤 export: что именно вы отдаёте наружу?

Из модуля наружу видно только то, что помечено export. Всё остальное снаружи не видно — но это не «закрытость» уровня файла: у непомеченных сущностей модульное связывание, то есть их видят другие единицы трансляции того же модуля, просто не видит код, который подключает модуль. Это противоположность заголовкам, где в чужой код текстуально попадает вообще всё.

export module geometry;

export struct Point { double x, y; }; // открыто наружу

double dist(Point a, Point b); // скрыто снаружи,
// но доступно внутри модуля

export double length(Point p) { // открыто наружу
return dist(p, {0, 0});
}

Открыть наружу можно почти любую сущность: функции, типы, шаблоны, переменные, псевдонимы using.


🪐 Удобные формы записи

export { // блок экспорта
int foo();
int bar();
}

export namespace net { // только объявления ЭТОГО блока
void connect();
}

export import utils; // повторный экспорт: проброс
// чужого модуля дальше

❗️ export namespace открывает только то, что объявлено в этом блоке. Если позже снова открыть пространство имён net без export, новые имена наружу не уйдут.


❌ Ошибки

• export допустим только в единице, которая начинается с export module …;. В единице реализации (module geometry; без export) это ошибка компиляции
• export нельзя ставить на сущности в безымянном пространстве имён — у них внутреннее связывание
• функцию со static не открыть — она по определению локальна (внутреннее связывание)
• нельзя открывать что-либо из общей вступительной части модуля (того, что идёт до export module …;)

⚙️ TypeScript без V8: AOT-компиляция в нативный бинарник

В МойОфисе уперлись в санкционные ограничения Qt и медленную разработку UI на C++. Решение — компилировать TypeScript в натив напрямую, без браузера и интерпретатора.

• Фронтенд компилятора написан на самом TS и крутится в Node.js: переиспользуют парсер и AST от Microsoft

• Выход фронтенда — LLVM IR, дальше стандартный бэкенд LLVM и llc. По сути поток компиляции концептуально идентичен Clang

• Свой JS-рантайм (TSNative STD): базовые типы ECMAScript, GC, event loop — всё, что обычно даёт V8

• Сопоставление TS-вызовов с C++-символами идёт через .d.ts-декларации и nm: ищут по обычному имени, вставляют в IR mangled

Точка входа живёт на стороне C++: она инициализирует рантайм и дёргает единственный экспорт tsmain, в который слинкован весь TS-код как статическая библиотека (extern «C», с оглядкой на ABI)

👉 Статья
👉 Видео

⛄️ Почему find_package(Foo) ищет в двух режимах?

Многие думают, что find_package — это «одна команда, один поиск». На деле под капотом работает диспетчер двух разных механизмов, и путаница между ними — частая причина «package not found» при идеально установленной библиотеке.

🔍 Когда вы пишете find_package(Foo), CMake по умолчанию сначала запускает Module mode: ищет файл FindFoo.cmake сперва в CMAKE_MODULE_PATH, а затем во встроенных модулях самого CMake. Это скрипт-разведчик, который через find_path/find_library сам ищет заголовки и библиотеки на диске.

⚡️ Если модуль не найден, включается Config mode: CMake ищет FooConfig.cmake или foo-config.cmake — файл, который поставляет сам пакет и который точно знает, где что лежит.

❗️ Важно: это последовательный поиск с откатом, а не параллельный. И порядок можно перевернуть — с CMake 3.15 переменная CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON заставляет сначала пробовать Config.

find_package(Foo) # сначала Module, потом Config
find_package(Foo CONFIG) # только Config mode
find_package(Foo MODULE) # только Module mode

❗️ Ключевое различие: FindFoo.cmake пишет кто угодно, кроме автора пакета — потребитель, сторонний разработчик или сами разработчики CMake (так поставляются FindThreads, FindOpenSSL и т.д.), и он угадывает расположение. А FooConfig.cmake поставляет сам автор библиотеки, и он обычно отдаёт готовые импортированные таргеты (Foo::Foo) с уже прописанными путями, флагами и зависимостями. Поэтому Config mode почти всегда надёжнее.

💡 На практике: если современная библиотека (через install(EXPORT)) не находится — проверьте не CMAKE_MODULE_PATH, а CMAKE_PREFIX_PATH, потому что искать нужно именно Config-файл.