C++ Siberia 2020: Антон Полухин - Незаменимый С++ 

> Для вызова кода из с++ из библиотеки нужно обернуть его в unsafe. А unsafe делает код на раст менее безопасным. Кажется это ввзов функции на c++ делает его менее безопасным :)

Спасибо, было интересно.

Лютейше интересно слушать.

смотрю из 2023, std::format до сих пор нигде, держу в курсе

Благодаря таким парням С++ рулит!

Кто может сказать что за библиотека регулярок от "Ханны" ? Как это гуглиться?

В списке сравнений языков нет Visual Basic, случайность? или боязнь конкуренции? :))

На отсутствии изкоробочности расплакался

достаточно исключить то что нельзя сделать на cpp

Carbon?

А как называется сервис, в котором код в ассембли переводится

3D моделирование? Не всё так однозначно, Blender на голёмом C по большей части, ровно как и многие-многие программы микроконтроллеров Так что выбора по крайней мере два

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

Интересно узнать, как в mission critical приложении на С++ заменить, скажем без изменения полей, метод в классе, не останавливая приложение ? А если изменились поля ? А если в новом коде ошибка, как не упасть или подняться после падения. Это к тому что С++ НЕ универсален, и вообще такого универсального языка быть не может. Если вы надёжно реализуете такой функционал, то получится очередной Common Lisp, Erlang, Java etc. и замедление в тех аспектах, которые потребовали специальных приседаний. Фанатики С++ часто упускают из вида, что язык для базовых задач конечно близок по производительности к Си и за счёт метапрограммирования даже может его где то обходить, но если добавлять специфику, от былой шустрости не останется и следа ! Монструозная система классов, шаблонов и прочих нагромождений из новых стандартов это скорей попытка сохранить универсальность, чем реальная помощь в какой то задаче. Кроме того это в некотором роде давно устарело, например говорилось про перевод шаблонов для использования в constexpr окружении. Но давным давно существовали языки, которые могли в compile time использовать сами себя для определения всех конструкций, а С++ лишь очень частично реализовал этот функционал и использует не полноценный С++, а весьма урезанный по функциональности, а до этого вообще была эра извратов на шаблонах.

Всё так, только Senior C++ Dev получает зарплату как Junior Java Dev. Как так?

Managed язык не может работать без виртуальной машины, писанной на С++. С чего бы это ? Такую машину можно написать на любом другом "системном языке", хоть Pascal, скорей всего Си, так как для С++ там и размаха толком не будет. Кроме того у С++ такой жирный рантайм, что до недавнего времени писали на С, чтобы влазило в контроллеры, я работал в такой конторе !

Проблема остановки -- фундаментальная проблема теории алгоритмов. А спикер хочет что бы раст ее смог решил

Если №6 переформулировать как "сборка мусора дешевле чем ручное управление" то оно уже не будет заблуждением. Понятно что так или иначе памятью приходится управлять, но "микроменеджмент" с постоянными "микропроверками" на предмет живо оно или уже нет выходит дороже.

Решающее значение имеет не удобство написания кода, zero abstraction, memory safety, и прочие технические детали, а пресвятая пара: СТАНДАРТ и КОМИТЕТ. Без СТАНДАРТА и КОМИТЕТА проекты с жизненным циклом более 30-ти лет: такие, как те же Unreal Engine или WebKit - в принципе невозможны. Язык, обделённый СТАНДАРТОМ и КОМИТЕТОМ, и как следствие, имеющий только одну реализацию, а не множество альтернативных - на длинной дистанции обречён. Как обречена и Мозилла, затеявшая весь этот блудняк с мертворожденным Servo и новым языком под него, вместо концентрации на реально хорошем Firefox.

Мне нравится современный C++ по сравнению со всеми альтернативами, Rust не греет ни разу. Здесь я написал много, но критикую лишь необъективность высказываний и в прошлом имел дело с радикалами от крестов :-) По поводу сборщика мусора тот самый случай: подмена понятия "стоимость управления памятью" на "накладные расходы на сборку мусора". Извините, но в общем управлением памятью особенно через архаичные счётчики ссылок тоже не обходится далеко не бесплатно и не только во время выполнения ! В коде где происходят массивные перемещения всяких динамических структур RAII уже практически бесполезно, и заметно, что там, где разработчики чувствуют себя свободнее в плане управления памятью, и алгоритмы совершеннее (динамические языки, функциональные языки). Преждевременная оптимизация часто стоит очень дорого, вплоть до отказа от языка (одно из слабых мест C++ в современной разработке из-за чего могут выбрать Java или C#). Сборщики мусора бывают Real Time (т.е. гарантирующие некое время отклика системы), тем более современные сборщики обычно многопоточные и не тормозят-лочат весь мир. Бывают как Erlang машине локальные "сборщики", очень эффективные, на них никто ещё не жаловался. Есть же сборщики и для C++, почему его надо противопоставлять управляемым языкам ??? Архитектура может быть разной. Почему бы крупные объекты не держать на сборке, чтобы удешевить разработку, а мелкие передавать по значению и локально по ссылкам ?

эх, используется везде, а вакансий нет

Насчёт Java, забавно слышать это на фоне успеха Java под Android, вроде вопрос размера виртуальной машины и библиотек там никого не колышит.

А разве что-то может заменить С++?

ИМХО, область применения manage-языков намного шире, чем область применения С++. И вот почему. 1. На несколько порядков иной раз легче порог вхождения. Следовательно ресурс из рабочей силы более доступен нанимателю. Кроме того, с помощью manage-языков часто гораздо быстрее создать работающий прототип приложения, чем на C++. А это иной раз может быть огромным конкурентным преимуществом в сравнении с иной раз мифической производительностью C++. Почему мифической? Потому что для того, чтобы её достичь на практике (а не в теории), надо обладать очень глубокими знаниями, как в области алгоритмизации, так и в особенностях языка и соответствующих программных инструментов. О чём чуть ниже. 2. Далеко не везде нужна сверхпроизводительность. А там, где нужна, часто (не всегда) дешевле купить более мощное железо, чем содержать команду высококвалифицированных программистов на C++. Да и не факт, что эти программисты действительно высокопрофессиональны. Читал рассказ, как один человек за 6 месяцев с помощью F# оптимизировал на известной американской бирже то, что команда из примерно 20 программистов (точную цифру не помню, но она близка к этой) на C++ не смогла за несколько лет. Приводить компании мирового уровня для того, чтобы оправдать 5% прироста производительности в датацентрах - это манипуляция в чистом виде, потому что ну сколько на самом деле таких компаний? 3. Ошибки программистов, исправляемые в автоматическом режиме интерпретаторами и/или компиляторами manage-языков, обходятся намного дешевле, чем ошибки программистов на C++. В начале выступления прозвучал тезис о том, что C++ безопасен. И откуда столько новостей о memory leaks в разных продуктах, написанных на C++? И почему программисты из Microsoft решили очень настойчиво посмотреть в сторону того же Rust? Конечно же я не пытаюсь отрицать важность необходимости C++ в настоящее время. Просто не понравились манипулятивные выпады в выступлениях Антона в сторону manage-языков. Недостатки их он как бы указал, но о преимуществах решил подзабыть (разве что к самому концу обозначив недостатки C++, которые одновременно являются преимуществом manage-языков). PS. Про поддержку стандартов C++ его компиляторами - это отдельная интересная тема. Стандарты как бы есть, а вот полноценная поддержка далеко не всегда присутствует, а если присутствует, то не всегда в полном объёме. Такая себе "кросс-платформенность". Почему выступающий об этом ничего не сказал, остаётся только догадываться. en.cppreference.com/w/cpp/compiler_support

Антон опрокинул Rust ))))

Ничем

Кто бы что не говорил С++ хороший язык программирования. А изучение Rust - это риск, так как он может завтра умереть и есть ряд других причин отсутствие вакансии, комьюнити и т. д. . Так что С++ намного предпочтительнее.

Думаю это выдача желаемого за действительное, включая банкомат, на кой там С++ ???? С++ якобы везде, но доказательств этому нет. Например в Machine Learning рулят Python, Julia, R, может Яндекс что то скрытно пишет на С++ ? :-) Если бы всё писали на С++, то было бы море вакансий. Но фактически бизнес компании пишут на C#, Java, Python. Под контроллеры по крайней мере ещё недавно большей частью галимый Си, его то не надо с С++ смешивать, это совершенно другой язык, это к вопросу о дефибрилляторах :-) Ядра каких ОС написаны на С++ ? Их можно пересчитать по пальцам. С++ в Mission Critical приложениях ? Это жестоко. Тот же Erlang не свалить, а С++...хе хе. Кроме того С++ не годится там где надо на DSL часто менять некие описания, сценарии и т.п., хотя может кто то так и делает (злобные такие буратины). То что Яндекс его применяет, это такая фишка самого Яндекса. Крупномасштабное проектирование на С++ довольно сложная штука, язык требует слишком много внимания к низкоуровневым деталям, не давая сосредоточиться на крупных аспектах. Если у кого то получается, это не достоинство языка, а умение хождения по граблям, достигнутое годами тренировок. Получается полезная штука, но переоценивать не стоит.

Уже давно заменимый

Навязчивый маркетинг и враньё :-)