Переход с Java на C++

Для С++ pkg-config также используется. Пакетным менеджером в данном смысле слова он, кстати, не является.

pkg-config указывает пути к либам. Он их не собирает. В этом проблема.

это называется «поддержка модулей» и она должна быть на уровне языка а не инструментов.

Ну, современный C++ странный весьма бывает. Я вот, например, так и не понял сакрального смысла header-only библиотек, от которых линтеры типа intellisense и прочие просто выжирают всю память и падают, а сборка одного файла превращается в длительное ожидание.

Это говно у тебя, а не header-only библиотеки.

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

А pip в питоне это язык или инструмент? Для языка слишком большое расширение.

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

это называется «поддержка модулей» и она должна быть на уровне языка а не инструментов.

Уже ведь есть модули на уровне языка. Пусть это и эксперементальная фича, но стандарт C++20 вот вот примут окончательно, а модули уже появились даже в MSVC.

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

Кроме того сборочные системы неизвестно когда добавят полноценную поддержку модулей. Даже в основных компиляторах (clang, gcc, msvc) еще нет полной поддержки модулей...

Странно, а вот тут заявляют частично обратное:

https://docs.microsoft.com/en-us/cpp/cpp/modules-cpp

C++20 introduces modules, a modern solution for componentization of C++ libraries and programs. A module is a set of source code files that are compiled independently of the translation units that import them. Modules eliminate or greatly reduce many of the problems associated with the use of header files, and also potentially reduce compilation times.

Даже в основных компиляторах (clang, gcc, msvc) еще нет полной поддержки модулей...

Да, по крайней мере в msvc эта поддержка не полная, но она уже есть.

Странно, а вот тут заявляют частично обратное:

вот статейка про модули в MSVC: https://devblogs.microsoft.com/cppblog/standard-c20-modules-support-with-msvc-in-visual-studio-2019-version-16-8/

для начала не мешало бы подучиться и различать сам язык и функционал реализован на нем.

В чем разница, о мастер?

Согласен, неправильно выразился. И нем не менее его философия (имхо) очень правильная.

Я говорю про выжирание памяти линтером. Простота подключения библиотеки это очень так себе аргумент: это нужно делать один раз. А компилять каждый раз, когда что-то поменял.

О, а вот это что-то очень и очень интересное, спасибо упустил как-то.

Я говорю про выжирание памяти линтером. Простота подключения библиотеки это очень так себе аргумент: это нужно делать один раз. А компилять каждый раз, когда что-то поменял.

и какая разница, что компелять каждый раз?

Header-only вообще не отличается от обычной библиотеки, в этом плане.

Нормальная header-only библиотека выглядит как-то так

#pragma once;

void test();

#ifdef NEED_IMPLEMENTAION_MY_SUPER_LIB
#include <stdio.h>

void test()
{
    puts("Hello");
}
#endif

Линтер видит ровно тоже что он видел бы и для обычной либы(лишь declaration функций/классов)

А ты просто добавляешь к своему проекту, один cpp файл, и в нём.

#define NEED_IMPLEMENTAION_MY_SUPER_LIB
#include "my_super_lib.hpp"

во всех остальных cpp файлах, просто делаешь include, без define.

Подключение такой библиотеки проще, для линтеров/анализаторов/времени компиляции компилятором разницы никакой, по сравнению с не header-only библиотекой.

в том что pip по сути загружалка/копировалка. А в языке уже работа с помощью ключевого слова import, которая заставляет компилятор искать модули по sys.path или по текущей папке.

Собственно компилятор содержит менеджер модулей в себе. Осуществляет поиск, запуск, разруливания имен. А pip - менеджер пакетов.

Собственно умники выше пишут что нужен менеджер пакетов. Хотя менеджер пакетов для С чуть ли не git clone, грузит копирует, версирует, патчит и даже сабмодули держит. Только этого ничего не даст. Все равно нужно хейдера и исходники скармливать ручками компилятору. Поддержки на уровне языка нет.

Тот же принцип в расте. Только ключевое слово mod. Имя модуля и есть имя файла. А менеджер пакетов Cargo это просто, грубо говоря, «git clone», которые стягивает в текущую папку сорцы. Собственно все сорцы скопом собираются в один испольняемый модуль. Ну как собираются!? Передаются LLVM, а он уже все генерит.

Т.е. скачиваешь папку с сорцами раста. Заходишь в папку с main.rs. Пишешь rustc main.rs и оно само гуляет по дереву каталогов и присоединяет/компилирует нужные файлы. На выходе main.exe. Если что-то внешнее - юзаешь extern. Это все можно делать и без Cargo.

Т.е. Cargo подкидывает нужные сорцы за тебя и и за тебя вызывает команду rustc. Удобная софтина-обвертка, чтобы одной командой все это делалось.

Для языков С/С++ нужно и свое ключевое слово import и свой pip. Потому что каждый файл cpp по сути отдельная прога, которые в свою очередь вскармливаются линкеру.

В С/С++ просто это делает сам программист, а в Rust, Python делает за тебя компилятор.

Собственно отсюда трагедия.

А менеджер пакетов Cargo это просто, грубо говоря, «git clone»

Это даже не 1% его фич.

которые стягивает в текущую папку сорцы

Ниет. В ~/.cargo

Ну как собираются!? Передаются LLVM, а он уже все генерит.

Царь покусал? В LLVM передаётся IR.

Удобная софтина-обвертка, чтобы одной командой все это делалось.

Ага. И поэтому эта «обёртка» содержит 40 KLOC без зависимостей.

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

В LLVM передаётся IR.

Типа я не знал да! Ты решил к словам придраться?!

Ниет. В ~/.cargo

Охиренно поменяло ситуацию.

Ага. И поэтому эта «обёртка» содержит 40 KLOC без зависимостей. Это даже не 1% его фич.

… которые нафиг не нужны. Щас ты будешь впадать в крайности до полного обсурда, лишь бы убедить меня как это важно и что это кулл, чтобы в конечном итоге последнее слово осталось за тобой чисто из принципа.

Как раз для полноценной либы, которая уже закомпилирована в виде .so, .a - линтер видит только прототипы классов/функций. Реализация откомпилирована и скрыта. А в типичном header-only дикое количество STL’я, по которому приходится елозить линтеру и компилятору вообще каждый раз. Далеко ходить не надо: ExprTk, easylogging++ и header-only либа для json уже достаточно чтобы получить очень много боли.

Как раз для полноценной либы, которая уже закомпилирована в виде .so, .a - линтер видит только прототипы классов/функций.

Я так понял это слив. Линтер смотрит уже на препроцессированные файлы, а для header-only библиотек с такой структурой как я описал, «полноценные» либы не отличаются ни на йоту от header-only

Ну и вот тебе пример хороших header-only библиотек, чтобы показать, что это не только я про них знаю:

https://github.com/nothings/stb

Тут даже есть заметка, на что обращать внимание, если хочешь писать свои хорошие header-only библиотеки: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt

https://github.com/nothings/stb

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

Я так понял это слив. Линтер смотрит уже на препроцессированные файлы, а для header-only библиотек с такой структурой как я описал, «полноценные» либы не отличаются ни на йоту от header-only

Чувак, я не спорю что можно писать нормальные header-only либы, и может быть даже повезет и .cpp включающий больше 2-3х таких либ не будет собираться вечность.

Но по факту, мой опыт с header-only либами и пары коллег это никак не меняет (специально тебе привел конкретный юз-кейз). Выходит больно и медленно. Время выигранное от удобств синтаксиса и простоты подключения десятикратно просирается пока ты тупо ждешь пока соберется софт/редактор отвиснет.

Хак с NEED_IMPLEMENTAION_MY_SUPER_LIB конечно хорош, но у меня ощущения что многие на это тупо забивают болт или вообще тыкают static inline’ы. Sad, but true.

И да, я с временем сборки загоняюсь. Если на итерацию пересборки требуется больше 45 секунд это уже субоптимально в моем понимании.

Вопрос к плюсовикам. Скажите, а есть ли у вас что-то типа jug.ru в youtube, проводящее аналогичные мероприятия с интересными докладами. Было бы интересно послушать.

Вот, сам спросил и сам нашёл:
https://www.youtube.com/c/CUserGroupRussia/videos

Если есть что-то ещё, буду рад послушать.

интересные доклады: https://www.youtube.com/user/CppCon/videos

CppCon, CppRussia более на слуху. Но кмк конференции по C++ это больше спецолимпиада спортсменов по языковым выкрутасам, чем полезные на практике знания.

Спасибо! У меня информация была не с официального источника: доклады по модулям Дмитрий Кожевников — Модули в С++20 — правда или вымысел(с таймкодом) Плюс синтетические тесты(к слову, на 8, 12 потоках модули выглядят прилично): Сравнение скорости билда

Можно еще CoreHard добавить, наверное: https://www.youtube.com/channel/UCifgOu6ARWbZ_dV29gss8xw

Ну почему же? Вот интересный не длинный доклад и ещё более интересное обсуждение после него. Там началась дискуссия о расширении стандартной бибилотеки C++. Несколько участников дискуссии предложили добавить пакедж менеджер и не увеличивать объём стандартной библиотеки - не тащить туда всё подряд, что далеко не везде нужно. Докладчик с ними не соглашался и парировал аргументами типа: «а вот в Java объём стандартной библиотеки больше, чем в C++ и ничего, под Android всё работает». В общем интересно послушать:

https://www.youtube.com/watch?v=g2iyNH2Gh1k

Да, тоже интересно. Спасибо.

Ясно, спасиб. В С++20 модули добавили, правда реализованы они везде не полностью, да и пакетного менеджера нет. Придется по старинке всем велосипедить.

Кстати про пакетный менеджер. Выше я дал ссылку на youtube ролик с докладом Антона Полухина из stdcpp.ru на С++ User Group и там как раз это, среди прочего, обсуждают после доклада. Сам докладчик дал понять, что он и комитет стандартизации C++ против этой идеи. Интересно, чем вызвана такая неприязнь к пакетным менеджерам? Job security? Антон рассказал, что на большенстве платформ разработкой стандартной библиотеки занято не более пяти, а обычно лишь один человек. Если не расширять стандартную библиотеку, у этих людей не будет работы?

Если на Яве мне придется сделать один-два шага в сторону того, чего не позволяет JVM из коробки, а именно доступ к аппаратуре, взаимодействие с драйвером железа или, обожемой, потребуется реализовать zero-copy при общении с железом, 

Для такого да, ява никак. Но блин количество софта, которому все это нужно, не шибко большое

у питона совместимость приходится тестировать

Я больше про совместимость версий на одной платформе. Кросс-платформенность всегда боль

Ага, ну тут уж издержки профессии)

ну тут уж издержки профессии

Аналогично. Писать бэк веба на крестах это бдсм для ценителей. И ml на разовых заказах тоже.

https://www.youtube.com/watch?v=W9DBJunyZyQ

Довольно интересный доклад Павла Филонова о conan.io - пакетном менеджере для C/C++ проектов и организации CI/CD с его помощью. Докладу скоро исполнится 4 года и надо полагать, что многие затронутые проблемы уже решены и сейчас conan.io выглядит ищё более привлекательным.

Как свитчнувшийся на C++ 7 лет назад могу заявить, что ради самого языка смысла переходить может и немного (хотя сам C++ мне нравится намного больше жабы из-за возможностей метапрограммирования и комплайл тайм вычислений, а так же большими возможностями в плане функциональщины). Но много смысла в переходе из-за того, что задачи на C++ бывают много интереснее любых задач, решаемых на Жабе - HPC, графика, алгоритмы и вот это все vs Энтерпрайз со скучной бизнес логикой.

Расскажи про задачи, которые решаешь на C++ теперь.

Десктопная софтина, которая отчасти 3D редактор, отчасти CAD и предназначена для работы с оптическими и лазерными 3D сканерами.

$ man BDSM

А зачем нужен этот С++, кроме как в компании Oracle, которая на C++ пишет JVM?

А зачем переходить? Не проще использовать плюсы обеих систем? В GraalVM подвезли интероп с сями, в панаме пилят удобный интероп с сями из JVM. Подключай нативные либы, а остальное пили на джаве. За этим подходом будущее, пока не изобрели нормальный ЯП.

https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md

Я совсем не против.