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

— —
. . . Каждый новомодный язык программирования норовит заявить о том, что он быстрее, надёжнее и вообще по всем параметрам в несколько раз лучше C++

[pavel_trpn]

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

[zeOnni]

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

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

[andrewbirs]

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

[sergeiepatov]

Решающее значение имеет не удобство написания кода, zero abstraction, memory safety, и прочие технические детали, а пресвятая пара: СТАНДАРТ и КОМИТЕТ.

Без СТАНДАРТА и КОМИТЕТА проекты с жизненным циклом более 30-ти лет: такие, как те же Unreal Engine или WebKit — в принципе невозможны.

Язык, обделённый СТАНДАРТОМ и КОМИТЕТОМ, и как следствие, имеющий только одну реализацию, а не множество альтернативных — на длинной дистанции обречён.

Как обречена и Мозилла, затеявшая весь этот блудняк с мертворожденным Servo и новым языком под него, вместо концентрации на реально хорошем Firefox.

[mvolloshin]

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

[daishinkan]

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

[sergeyvoloshin]

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

[IExSet]

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

[IExSet]

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

[ДанилаГладкий-лк]

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

[zeOnni]

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

[IExSet]

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

[avazart]

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

[IExSet]

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

[anst]

ИМХО, область применения 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++ его компиляторами - это отдельная интересная тема. Стандарты как бы есть, а вот полноценная поддержка далеко не всегда присутствует, а если присутствует, то не всегда в полном объёме. Такая себе "кросс-платформенность". Почему выступающий об этом ничего не сказал, остаётся только догадываться.

[denispriyomov]

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

[vladshut]

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

[denizzzka]

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

[nicolasteylor]

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

[cppprograms]

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