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

Ответь про раст, правда интересно.

Я не вижу вопроса.

Rust там для галочки.

Ещё зависимость может не иметь исходников (раст так может, кстати? Наверное надо будет делать биндинг?), тогда просто скачать и все.

Вопрос спрятан в скобочках!

Вот кстати Makefile на самом деле отличная тема. Особенно если нужно больше контроля за сборкой

Линковаться к сишной либе? Так же как и в C/C++. Пишем «хедер» и вперёд.

В данном случае речь идёт о переходе лишь на C++, причём современный.

Я не знаю, какие задачи можно выполнить лишь на C++. Например, там даже работу с директориями внесли только в C++17. Там же никаких батареек нет. GUI нет, работы с сетью нет, даже работы с XML или JSON нет. Ввод-вывод в консоль сильно урезан. Даже «Press any key» не сделать, не говоря уже о цвете шрифта. Да и «Press Enter» с сюрпризами будет если использовать потоки ввода-вывода.

То есть надо будет какой-то фреймворк изучить. В данном случае переход с Java на C++ возможен, если верить сообщению от Reset: Переход с Java на C++ (комментарий)

современные программисты на C++ уже почти перестали пользоваться операторами new и delete.

А чем они пользуются сейчас? shared ptr?

Кто в здравом уме юзает мезон в яве?

А чем они пользуются сейчас? shared ptr?

Да, различными обертками над сырыми указателями.

Я перешел, в принципе ок. Главное работать в коллективе где банят сильно магический код. От C++ нужно максимум набор фич на уровне Delphi,тогда он готов к продакшну

Что писал на Java и что пишешь сейчас?

Есть вполне себе годный cmake, и более новый и сырой meson. Я пока предпочитаю cmake, хотя meson имеет все шансы стать мейнстримом.

Раньше финансовое говно для инвестбанков. Теперь облачную автоматизацию на Go и C++ для деплоймента софта

Но это решительно ничего не меняет.

Не меняет чего? Что C++ простой и лаконичный язык? Это бравада. Типа «а хули там делать?», «а что там сложного», «да это просто». Ок. Твое субъективное «просто» - это величина в твоей системе координат. Мне тоже сейчас C++ - это просто после нескольких лет изучения и практики. Но так или иначе, тот же python освоить раз в десять быстрее и дальше уже изучаешь задачу и алгоритмы решения. Важно насколько быстро достигается это просто.

Есть вполне себе годный cmake

Ты серьёзно? Ты правда считаешь cmake нормальным?

хотя meson имеет все шансы стать мейнстримом

Дай Бог, этого не произойдет. Может он и не плох, но бля за*бали. Одна система сборки, вторая, третья… Постоянное перескакивание с одной системы сборки на другую, использование в одном проекте разных библиотек, каждая со своей системой сборки. Тоже и с языками - нам мало языков программирования в 2020, у всех существующих фатальные недостатки, давайте придумаем самый самый лучший.

Я считаю CMake нормальным. Отличная кроссплатформенная система сборки. Использую ее на винде и на линуксе. Есть все что мне нужно. Можно сделать сложные тонкие действия в процессе сборки.

Можно сделать сложные тонкие действия в процессе сборки

Вот это реально большое фу. Сборка должна быть простой как тапок. В гредле тоже можно прям в билд-скрипте грувей напердячить. И через полгода вообще не врубить как оно работает. Если прям надо тонко - отдельный модуль в виде чёрного ящика и с максимально вменяемым интерфейсом

В какой среде работаешь с кодом? OS, IDE, система сборки.

Chrome OS, внутрення система сборки (версия bazel) и IDE. Компанию угадаешь

Сборка должна быть простой как тапок

В CMake все достаточно лаконично. Не хочешь сложный действий - не делай.

И через полгода вообще не врубить как оно работает

Ну пиши нормально. Говнокод везде опасность несет.

Если прям надо тонко - отдельный модуль в виде чёрного ящика и с максимально вменяемым интерфейсом

Отдельный модуль для чего?

В любом случае в CMake можно оформить дополнительные действия в отдельном *.cmake файле и вызывать как функцию.

Про IDE не понял. У вас собственный IDE?

В браузере, да

C++ IDE в браузере?

Да

Ты точно про YDB, а не про YT? Второй как то ближе к Hadoop, как по мне.

Ну и ты не сравнивай Яндексовую экосистему плюсов с плюсами во внешнем мире.

Как минимум в Яндексе монорепа, решающая проблему dependency management, своя система сборки, унифицированно собирающая на разных платформах, своя стандартная библиотека и куча всего другого, упрощающего жизнь человека, которому хочется поправить что то в плюсовом проекте.

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

Ты точно про YDB, а не про YT? Второй как то ближе к Hadoop, как по мне.

Я про hadoop-стек: https://sranka.wordpress.com/category/hadoop/ YDB и YT в некотором смысле близки.

Как минимум в Яндексе монорепа, решающая проблему dependency management, своя система сборки, унифицированно собирающая на разных платформах, своя стандартная библиотека и куча всего другого, упрощающего жизнь человека, которому хочется поправить что то в плюсовом проекте.

Это много где так.

Да. При всех его минусах, с ним можно сравнительно просто обеспечить совместимость win/lin/mac, и по одной кнопке генерировать проект для тех, у кого палец прирос к visual studio или другим средам. В добавок очень просто подцеплять подпроекты, много библиотек его и так используют. Для ctest есть готовая интеграция в Jenkins. Не идеальное решение, но на сегодняшний день лучшее (имхо), что есть.

Зависит от задач. Для чего-то сложнее хеллоуворлда надо уметь инструментировать код для сбора покрытия/профилирования, прогонять статический анализ, и ещё дофига всего.

надо уметь инструментировать код для сбора покрытия/профилирования, прогонять статический анализ

Ты ведь понимаешь что в случае той же явы ты цепляешь плагин к мавену и даже не думаешь об этом всем

Для ctest есть готовая интеграция в Jenkins

Для явы есть xunit, для питона есть pytest-cov и тонна других обвязок

можно сравнительно просто обеспечить совместимость win/lin/mac

О чем в случае явы/пистона обычно даже думать не надо

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

Ну я бы перешёл, если бы возникла такая ситуация. Просто C++ гораздо сложней Java. Думаю, что мне понадобилось бы не меньше года, чтобы выйти на уровень хотя бы среднего C++ программиста. А в обратную сторону, если нет необратимого повреждения мозга пересчитыванием битов, имхо, потребовалось бы пару месяцев. При том, что спрос на C++ в разы меньше спроса на Java, вероятность такой ситуации просто слишком низкая. Вот и не переходят.

Я не знаю, какие задачи можно выполнить лишь на C++

Ты пишешь «лишь на С++», но подразумеваешь «лишь на стандартной библиотеке С++».

Например, там даже работу с директориями внесли только в C++17

Boost.Filesystem, с которой с минимальными правками скопировали std::filesystem, существует с начала нулевых.

Там же никаких батареек нет. GUI нет, работы с сетью нет, даже работы с XML или JSON нет.

Зачем эти вещи в стандартной библиотеке? Чтобы ее переписывать постоянно?

Ввод-вывод в консоль сильно урезан. Даже «Press any key» не сделать, не говоря уже о цвете шрифта.

«Press any key» и цвет шрифта как минимум не поддерживаются на большом количестве старых устройств, да и вообще крайне платформозависимы. Зачем они в стандартной библиотеке?

«Press any key» и цвет шрифта как минимум не поддерживаются на большом количестве старых устройств

Можно перечислить эти устройства?

Зачем эти вещи в стандартной библиотеке?

В python есть, в C# есть. Можно без дополнительных библиотек сразу писать какое-то полезное ПО. Более того, в доисторическом паскале было больше полезных модулей из коробки.

Я понимаю подход разработчиков C и C++. Они дают только «скелет», а «мясо» поставляется отдельным поставщиком под определённую задачу. Если мы не говорим о лабораторной работе или простейшей утилите, то на одном «скелете» далеко не уедешь.

Но зарплаты у сишников немного выше. По крайней мере здесь.

«Press any key»
В python есть

И как?

Тут путаница в цитатах. Было так:

1. Я: GUI нет, работы с сетью нет, даже работы с XML или JSON нет.
2. Siborgium: Зачем эти вещи в стандартной библиотеке?
3. Я: В python есть, в C# есть.

Ну, если уж прикапываться к словам, то это именно вы предъявляли плюсам отсутствие этой фичи в стандартной библиотеке:

Ввод-вывод в консоль сильно урезан. Даже «Press any key» не сделать, не говоря уже о цвете шрифта. Да и «Press Enter» с сюрпризами будет если использовать потоки ввода-вывода.

Да, в питоне с этим тоже проблема. Но это не отменяет моей претензии к C++. Но в питоне хотя бы «Press Enter» можно сделать, если я не ошибаюсь.

Можно перечислить эти устройства?

Вообще, хотел отослать вас читать про ANSI escape codes и termcap/terminfo, но… Хотя еще остались печатные терминалы и голый ембеддед, я принимаю аргумент.

В python есть, в C# есть

Python и C# – это, внезапно, не С++. У них другое назначение и место в экосистеме. Никто не пишет те же GUI-библиотеки на чистом питоне или C#.

Если мы не говорим о лабораторной работе или простейшей утилите, то на одном «скелете» далеко не уедешь.

Возможно, стоит все же изучить предметную область перед тем, как куда-то «ехать»? Фреймворки – не магия, все когда-то пишется впервые. Зачем тянуть в стандартную библиотеку то, что уже хорошо работает отдельно?

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

Зачем тянуть в стандартную библиотеку то, что уже хорошо работает отдельно?

Незачем. Хотя я бы не отказался от языка, в котором была бы библиотека как у C#, но не требовалась бы виртуальная машина.

Возможно, стоит все же изучить предметную область перед тем, как куда-то «ехать»?

Так я с подобного утверждения и начал в этой теме.

Расскажу свою историю.

Я когда-то программировал на C++, но потом долгое время разрабатывал на Java. В один прекрасный момент захотел вернуться в мир C++ - и это было больно. Хорошо, что к этому времени уже подоспел Rust, на нем в итоге остановился - и в целом доволен своим выбором.

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

Про яву говорить не буду, а вот у питона совместимость приходится тестировать, причем серьезно. Не все расширения есть на винде, а некоторые тянут для сборки через pip Visual Studio Build Tools, а это гига 4 минимум качать из интернета. Молчу еще, что с дистрибуцией питоноприложения для винды отдельный геморрой.

Некоторые вполне себе простые конструкции ведут себя по-разному. (Например, open(«file.bin», «rb»), ‘b’ на винде обязателен, на линуксах как правило можно забить). И если в сторонней библиотеке на это забили, то ждет боль. Такие дела.

С java в теории все должно быть немного лучше, но там 3/4 библиотек которые (для нашей задачи) из коробки были в питоне, вообще не было. И GUI выглядит омерзительно, хотя это вкусовщина.

В общем, все хорошо в своей нише.

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

так и не понял сакрального смысла header-only библиотек

Смысл в отсутствии пакетного менеджера. Поэтому приходится страдать.

header-only библиотек подключать проще, для велосипедных систем сборок это может быть критично. А проблему с памятью, в теории, должны решить модули, на этапе компиляции уже можно строить зависимости.

Что характерно, для C есть pkg-config, который свое дело делает. Но его нигде кроме линуксов нет и мейнтейнеры RHEL’а умудряются вечно косячить с ним.

сакрального смысла header-only библиотек

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

Как сторонний «плюс» могу добавить, что так и код оптимизируется лучше (за счет инлайна многих вещей), и куда меньше проблем типа odr. Все ценой куда более медленной компиляции.