×Закрыть

C++ дайджест #6: огляд менеджерів пакетів

У випуску: конструювання об’єктів без копіювання, спільне використання PCH, відео про Сonan, книги про С++ 17.

Привіт, мої любі сішники! Цього разу пропоную поговорити про пакетних менеджерів для С++, проглянути декілька статей про нові стандарти С++, а також обговорити останні новини про улюблені інструменти для розробки. Починаємо? :)

Пакетні менеджери в С++

Пакетні менеджери, поряд із підмодулями git (стаття 1, стаття 2) чи git subtree(стаття 1, стаття 2) та системами збирання, є однією з чарівних паличок у організаціях середніх та великих проектів. Тож пропоную детальніше розібратися, яка зараз ситуація на цьому фронті. Давайте почнемо з гарної статті-огляду пакетних менеджерів та систем збирання та звернемо увагу на такі пакетні менеджери як:

С++ 17 та С++ 20

Цього місяця з’явилися такі корисні статті: про std::any з 17-го стандарту, про конструювання об’єктів без копіювання, Contracts в С++20 та про оператор кома.

Корисні посилання

Підтримка стандартів компіляторами

Спільне використання PCH

Профілювання використання пам’яті на Linux з Qt Creator 4.7

Стаття про оновлення препроцесора С++ в MSVC

Оновлення

розширення С++ під Visual Code, де додані нові API для автоконфігурації IntelliSense для CMake

Visual Studio 2017 version 15.8 Preview 4

Qt Creator 4.7.0

Qbs 1.12

GitLab (Community Edition and Enterprise Edition) 11.1 та 11.1.2

GitHub

GCC 8.2 з фіксами

LLVM 6.0.1

Unreal Engine 4.20

Відео

Про Сonan в 3-х частинах: part 1 part 2 part 3.

Цiкавенькi книги

C++17 STL Cookbook: Discover the latest enhancements to functional programming and lambda expressions від Jacek Galowic

C++17 — The Complete Guide вiд Nicolai Josuttis

Для новачків

Про Git

Гарна стаття про приведення типів

Хвилиночка флуду

Історія про одного програміста, який ніколи не вивчав С

The World Map of C++ STL Algorithms — світова карта алгоритмів STL

Шахи в 1кб для Sinclair ZX81 (1982 рік)


← Попередній випуск: C++ дайджест #5
Наступний випуск: C++ дайджест #7

LinkedIn

12 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Ситуація з "менеджерами пакетів"/"системами збирання" в С++ така сама як і з іншими компонентами: поки комітет не придумає/позичить в буста щось робоче, продовжуватимуться холівари.

Але до цього ще треба похолiварити про необхiднiсть включення їх до стандарту :D

Кто-то может рассказать, есть ли толк от менеджеров пакетов в C++, если в проекте используются коммерческие либы, которые априори никогда не появятся в репозиториях этих менеджеров?

Могу предположить, если эти либы лежат где-то у вас в хранилище, и используются в нескольких проектах, тогда толк может быть. Не тянуть их в каждый проект физически, а просто прописать их в зависимостях проекта, и пусть там уже пакетный менеджер их вытягивает.

в статье о системах сборки не хватает premake.github.io

cmake.org/...​dule/ExternalProject.html — думаю, для с++ есть смысл упомянуть и поддержать cmake way to perfection. Им ExternalProject_Add немного остается доработать, чтобы не использовать дополнительных 3rd party велосипедов для трэкинга зависимостей! :)

Ще є FetchContent. That is:

FetchContent_Declare(
  extern_catch2

  GIT_REPOSITORY https://github.com/catchorg/Catch2.git
  GIT_TAG        v2.2.3)

FetchContent_GetProperties(extern_catch2)
if(NOT extern_catch2_POPULATED)
  FetchContent_Populate(extern_catch2)
  add_subdirectory(
    ${extern_catch2_SOURCE_DIR}
    ${extern_catch2_BINARY_DIR}
    EXCLUDE_FROM_ALL)
endif()

Різниця в тому, що ExternalProject забирає залежності у build time, а FetchContent на етапі конфігураціі.

Я зазвичай в проекті роблю external/CMakeLists.txt де описую 3rd-party за допомогою FetchContent, як у прикладі вище. Потім в проектах (підпроектах) просто додаю залежності в target_link_libraries:

target_link_libraries(mylib_tests
  PRIVATE Catch mylib)

Modern CMake — цяця :)

з гарної статті-огляду пакетних менеджерів та систем збирання

С базелем уже столкнулся — ужас. Так что оценки автора там сильно субъективны.
Cmake прилично удобнее базеля, хотя в нем своих приколов море.

А за таблички поддержи стандартов — спасибо.

Интересно узнать более подробно о Базеле ваше мнение:)
Поделитесь?

Мне хватило танцев с ним при сборке tensorflow. А писать его развернутый анализ я не собираюсь даже.

Подписаться на комментарии