C++ Siberia 2020: Антон Полухин - Незаменимый С++
HTML-код
- Опубликовано: 3 окт 2024
- Подробнее о конференции C++ Russia: jrg.su/W8skjE
- -
. . . Каждый новомодный язык программирования норовит заявить о том, что он быстрее, надёжнее и вообще по всем параметрам в несколько раз лучше C++
Благодаря таким парням С++ рулит!
Антон Полухин - просто зверь в этом деле.
С++ рулит!!!!
Лютейше интересно слушать.
смотрю из 2023, std::format до сих пор нигде, держу в курсе
И код из примеров на расте и плюсах компилятся в одинаковый код на асм )
всегда есть fmt
> Для вызова кода из с++ из библиотеки нужно обернуть его в unsafe. А unsafe делает код на раст менее безопасным.
Кажется это ввзов функции на c++ делает его менее безопасным :)
В списке сравнений языков нет Visual Basic, случайность? или боязнь конкуренции? :))
он мёртв
Это сарказм?)
@@dont_know_who_ юмор :))
Угар
На отсутствии изкоробочности расплакался
достаточно исключить то что нельзя сделать на cpp
Даже то что можно сделать на С++ часто получается слишком дорого делать на С++. Достаточно исключить то, что нельзя сделать на Си или ассемблере :-)
@@IExSet Вы пишете какое то бла бла бла. Поконкретнее, пожалуйста.
Всё так, только Senior C++ Dev получает зарплату как Junior Java Dev. Как так?
это где такое видано?))
@@bigtuedsay В Питере года три назад, когда нас собирались "оптимизировать'. У вас разве не так?
@@bigtuedsay места разные везде. Вакансии на плюсах есть в местах куда Java никогда не придёт по причинам, как минимум, high load и embedded что разные стороны одной и той же проблемы "в железо не влазит/жрёт слишком много" и вот на примере этих двух областей может быть и зарплата и зряплата :)
Жаль в Зеленограде нет офиса, например, Яндекса :) не променяю я хорошую зарплату на ежедневные прогулки на работу и с работы по лесу.
@@bigtuedsay во, я понял где так. Меня сегодня очень настойчиво с формулировкой "разработчик программного обеспечения (в основном C++, немного Java (только в рамках Android), и совсем чуть чуть Python)" зовут Team Lead-ом в Java команду на зарплату 300к деревянных. И... в гробу я видел банковский сектор с их гестапо, пусть ищут дальше терпил и любителей концлагеря. Java очень много в банковском секторе, там конские зарплаты, но такое гестапо, что кроме как временную подработку я бы такое рассматривать не стал.
@@HedgehogInTheCPP Стоит во дворе автомат по продаже воды, в один морозный зимний вечер узрел на монохромном дисплее описание исключения, которое выкинула Java: будка к серверу подключиться не могла.
Так что всё индивидуально
Решающее значение имеет не удобство написания кода, zero abstraction, memory safety, и прочие технические детали, а пресвятая пара: СТАНДАРТ и КОМИТЕТ.
Без СТАНДАРТА и КОМИТЕТА проекты с жизненным циклом более 30-ти лет: такие, как те же Unreal Engine или WebKit - в принципе невозможны.
Язык, обделённый СТАНДАРТОМ и КОМИТЕТОМ, и как следствие, имеющий только одну реализацию, а не множество альтернативных - на длинной дистанции обречён.
Как обречена и Мозилла, затеявшая весь этот блудняк с мертворожденным Servo и новым языком под него, вместо концентрации на реально хорошем Firefox.
Спасибо, было интересно.
Интересно узнать, как в mission critical приложении на С++ заменить, скажем без изменения полей, метод в классе, не останавливая приложение ? А если изменились поля ? А если в новом коде ошибка, как не упасть или подняться после падения. Это к тому что С++ НЕ универсален, и вообще такого универсального языка быть не может. Если вы надёжно реализуете такой функционал, то получится очередной Common Lisp, Erlang, Java etc. и замедление в тех аспектах, которые потребовали специальных приседаний. Фанатики С++ часто упускают из вида, что язык для базовых задач конечно близок по производительности к Си и за счёт метапрограммирования даже может его где то обходить, но если добавлять специфику, от былой шустрости не останется и следа ! Монструозная система классов, шаблонов и прочих нагромождений из новых стандартов это скорей попытка сохранить универсальность, чем реальная помощь в какой то задаче. Кроме того это в некотором роде давно устарело, например говорилось про перевод шаблонов для использования в constexpr окружении. Но давным давно существовали языки, которые могли в compile time использовать сами себя для определения всех конструкций, а С++ лишь очень частично реализовал этот функционал и использует не полноценный С++, а весьма урезанный по функциональности, а до этого вообще была эра извратов на шаблонах.
Речь о динамической линковке в runtime? - LoadLibrary в Windows и dlopen/dlsym в Linux, но если нужно что-то общее, то можно поискать библиотеку (вроде boost.dll)
У вас проблема с проектированием, и от этого и все эти велосипеды
Майнкрафт поддерживает хорошую графику, просто надо указать качество текстуры и меняй спокойно
Потому что он уже переписан на с++ Майкрософтом
@@Roman-rx9op хахаха, от языка не зависит графика
@@daishinkan12 ещё как зависит. Если бы не зависела, то все писали бы графику на Python. Увы Python слишком медленный.
@@cppprograms5868 да, она не зависит. Python медленный, но это не мешает сделать какую нибудь 16к графику. Ты прочитай внимательнее
@@daishinkan12 в риалтайме?)
Кто может сказать что за библиотека регулярок от "Ханны" ? Как это гуглиться?
boost.hana
github.com/hanickadot/compile-time-regular-expressions
Hana Dusikova, Compile Time Regular Expressions
Managed язык не может работать без виртуальной машины, писанной на С++. С чего бы это ? Такую машину можно написать на любом другом "системном языке", хоть Pascal, скорей всего Си, так как для С++ там и размаха толком не будет. Кроме того у С++ такой жирный рантайм, что до недавнего времени писали на С, чтобы влазило в контроллеры, я работал в такой конторе !
Он не говорил, что не может работать без c++. Речь, которую ты слушаешь интерпретируй правильно. Без спорно можно использовать другие языки. Но КАК ПРАВИЛО используют C++ . Та же JVM на нём написана
Carbon?
3D моделирование? Не всё так однозначно, Blender на голёмом C по большей части, ровно как и многие-многие программы микроконтроллеров
Так что выбора по крайней мере два
наверное имеется ввиду С/С++
Насчёт Java, забавно слышать это на фоне успеха Java под Android, вроде вопрос размера виртуальной машины и библиотек там никого не колышит.
А вы уверены что приложение которым вы пользуетесь написано на java? 😂 Думаю от Java там лишь new Window(), а дальше управление на себя берет c++ или kotlin native. Есть правда и хуже вариант React/javascript 😅
Проблема остановки -- фундаментальная проблема теории алгоритмов. А спикер хочет что бы раст ее смог решил
Спикер хочет не чтобы она была решена в Rust, а хочет чтобы фанатики Rust не говорили что она решена в этом ЯП. И не решена она как раз потому что это фундаментальная проблема алгоритмов. А значит от ЯП решение проблемы не зависит
эх, используется везде, а вакансий нет
Это для эстетов язык. Я пользую изза скорости вычислений. Рчдом ниче не стояло. А так по быстрому прототип матлаб питон.
@@ЮрийПопов-л6я я использовал Python для прототипирования до 11 стандарта, зачем использовать после так и не придумал ибо потом переписывать всё равно на плюсы. На счёт матлаба: всё больше и больше математики появляется в плюсах из коробки, это очень радует.С каждым новым стандартом немного велосипедов из кода удаётся выкинуть и это очень хорошо, пусть оптимизации делает компилятор и гораздо большая команда математиков.
@@ЮрийПопов-л6я P.S. на математике из коробки правда торчат детали реализации в железе в области математики, но для общих целей подходит
sin(pi) = 1.2246467991473532e-16
cos(pi/2) = 6.123233995736766e-17
cos(pi/3) = 0.5000000000000001
всё стандартное, включая pi из C++20 numbers::pi_v
и хотелось бы использовать большие числа кроссплатформенно на уровне стандарта. Как с плавающей точкой так и фиксированные и целочисленные, ну т. е. 128, 256, 512 и 1024 битные как минимум.
На С++ вакансий нет?
А как называется сервис, в котором код в ассембли переводится
Нашел уже, если кому надо - godbolt
Компилятор
Godbolt
Мне нравится современный C++ по сравнению со всеми альтернативами, Rust не греет ни разу. Здесь я написал много, но критикую лишь необъективность высказываний и в прошлом имел дело с радикалами от крестов :-) По поводу сборщика мусора тот самый случай: подмена понятия "стоимость управления памятью" на "накладные расходы на сборку мусора". Извините, но в общем управлением памятью особенно через архаичные счётчики ссылок тоже не обходится далеко не бесплатно и не только во время выполнения ! В коде где происходят массивные перемещения всяких динамических структур RAII уже практически бесполезно, и заметно, что там, где разработчики чувствуют себя свободнее в плане управления памятью, и алгоритмы совершеннее (динамические языки, функциональные языки). Преждевременная оптимизация часто стоит очень дорого, вплоть до отказа от языка (одно из слабых мест C++ в современной разработке из-за чего могут выбрать Java или C#). Сборщики мусора бывают Real Time (т.е. гарантирующие некое время отклика системы), тем более современные сборщики обычно многопоточные и не тормозят-лочат весь мир. Бывают как Erlang машине локальные "сборщики", очень эффективные, на них никто ещё не жаловался. Есть же сборщики и для C++, почему его надо противопоставлять управляемым языкам ??? Архитектура может быть разной. Почему бы крупные объекты не держать на сборке, чтобы удешевить разработку, а мелкие передавать по значению и локально по ссылкам ?
Вы пишете: *Извините, но в общем управлением памятью особенно через архаичные счётчики ссылок тоже не обходится далеко не бесплатно и не только во время выполнения* Не извиняю. Архаичные счетчики несопоставимо дешевле мусоросборки.
Вы пишете: *В коде где происходят массивные перемещения всяких динамических структур RAII уже практически бесполезно* Это какой то бессмысленный набор слов.
@@princessmary5556 это враньё конечно, нифига не дешевле
@@princessmary5556 попробуйте соорудить некую сложную структуру вроде дерева с циклами пользуясь только классическим RAII на стеке, может поймёте о чём я. Сборщик мусора выигрывает за счёт "оптовости" когда огромное количество объектов друг на друга ссылаются и передаются туда сюда, постоянно щёлкать счётчиком и ссылка на общий счётчик вместе с самим счётчиком - не бесплатна, и может быть враждебна кэшированию в процессоре. Убирать поколениями или как Erlang целыми пулами может быть выгодней. И я даже не говорю, что это совсем невозможно реализовать в C++, может быть только в нём и возможно такое сделать на самом языке не вламываясь в компилятор.
@@IExSetЭффективность архаичных счетчиков очевидна любому человеку, который хотя бы чутка понимает принцип их действия. И нужно быть реально тупым дебилом, что думать, будто бы это вранье.
Если №6 переформулировать как "сборка мусора дешевле чем ручное управление" то оно уже не будет заблуждением. Понятно что так или иначе памятью приходится управлять, но "микроменеджмент" с постоянными "микропроверками" на предмет живо оно или уже нет выходит дороже.
Кроме того есть RT сборщики мусора и помогает умение не мусорить, чтобы не убирать.
ИМХО, область применения 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
Вы отстали от жизни и по факту верен только первый пункт, а именно быдлокодер обойдется дешевле. А дальше можно сразу не читать т.к. теорию алгоритмов обязан знать каждый нормальный программист.
@@Gimli_Dwarf Знать - это одно. А уметь всегда правильно применять - это совершенно другое. Вы всё-таки попробуйте не только прочитать дальше первого пункта, а ещё попытаться осмыслить с точки зрения работодателя эти тезисы. Можно было бы ещё добавить и просто производительность труда на разных языках в разных сферах применения при прочих равных условиях.
@@anst9017 так-то знать и означает уметь применять. Кто не умеет что-то применить значит он и не знает
@@Gimli_Dwarf Всего на свете знать невозможно. Это прекрасно продемонстрировал лектор (смотрите комментарии ниже от других пользователей).
@@anst9017 никто и не говорит о знании всего, но алгоритмы, принципы работы вычислительных машин и математику программист знать обязан. А то бывает такое, что большое О за мат воспринимают.
А разве что-то может заменить С++?
Зависит от предметной области.
В какой нише ?
Навязчивый маркетинг и враньё :-)
Ничем
Кто бы что не говорил С++ хороший язык программирования. А изучение Rust - это риск, так как он может завтра умереть и есть ряд других причин отсутствие вакансии, комьюнити и т. д. .
Так что С++ намного предпочтительнее.
про python тоже так говорили в начале 2000-х. Что мол зачем учить python если все вакансии для php и ruby on rails.
@@zxcq так по твоему надо ждать 20 лет?
Это и есть главное преимущество С++, что он хоть более менее всем знаком и как то живёт с припарками, хорошая поддержка, компиляторы и библиотеки. Насчёт "хороший язык программирования", кхм. Назвать это нагромождение стихийно образовавшихся фич хорошим в смысле красивым, язык не поворачивается. Фанатам крестов привет !
Спустя 3 года с выхода доклада Раст - цветет и пахнет. Популярность растет. Как пример - пустили в ядро линукс (а почему не пустили плюсы?). Хорошо, что не прогадал в свое время с выбором основного яп ) Выбравшим плюсы - сочувствую ...
@@ГерманМальцев-ш5ж С++ тоже процветает, но что будет потом узнаем.
Уже давно заменимый
Полтора часа опровданий того, почему автор до сих пор пишет на плюсах
Антон опрокинул Rust ))))
Попытался, скажем так.
Тем временем амазон AWS переходит на раст.
А вам не смешно с таких примеров, как были в докладе? Одним запросом гуглятся десятки примеров, где раст спасет, а C++ заставит неделями валгриндить
Думаю это выдача желаемого за действительное, включая банкомат, на кой там С++ ???? С++ якобы везде, но доказательств этому нет. Например в Machine Learning рулят Python, Julia, R, может Яндекс что то скрытно пишет на С++ ? :-) Если бы всё писали на С++, то было бы море вакансий. Но фактически бизнес компании пишут на C#, Java, Python. Под контроллеры по крайней мере ещё недавно большей частью галимый Си, его то не надо с С++ смешивать, это совершенно другой язык, это к вопросу о дефибрилляторах :-) Ядра каких ОС написаны на С++ ? Их можно пересчитать по пальцам. С++ в Mission Critical приложениях ? Это жестоко. Тот же Erlang не свалить, а С++...хе хе. Кроме того С++ не годится там где надо на DSL часто менять некие описания, сценарии и т.п., хотя может кто то так и делает (злобные такие буратины). То что Яндекс его применяет, это такая фишка самого Яндекса. Крупномасштабное проектирование на С++ довольно сложная штука, язык требует слишком много внимания к низкоуровневым деталям, не давая сосредоточиться на крупных аспектах. Если у кого то получается, это не достоинство языка, а умение хождения по граблям, достигнутое годами тренировок. Получается полезная штука, но переоценивать не стоит.
"В ML рулят Python, Julia, R,...откуда тут возьмется C++?" - tensorflow/pytorch/etc почти полностью написаны на C++, если исключить обертки, - вот numpy на C, но ему сколько лет уже, как говорится?) - Но тут больше ода соглашениям о вызовах будет, как мне кажется
"Фактически бизнес компании пишут на C#/Java/Python/Javscript/etc" - так и есть: продуктовые фичи в основном "доставляют" на том, на чем не нужно (по началу) заморачиваться о памяти и хотел было написать скорости, но тут уже давно не так, и вопрос состоит в том "на сколько быстро мы хотим чтобы что-то работало"
*что забавно: в том же питоне уже дошли до того уровня, что нормальный программист должен знать как структуру уложить в стэк без оверхэда (привет __slot__), а джависты compile-time фреймворки осваивают с кодогенерацией (привет Dagger), и много-много чего ещё в других языках, что приводит к мысли: "слушайте, а почему мы к этому пришли и почему стало так неудобно? - Вот в {await GetNextMyFavoriteLanguage()} это сделано лучше")
В общем, имхо, но фраза "Если у кого то получается, это не достоинство языка, а умение хождения по граблям, достигнутое годами тренировок" скорее относится ко всем языкам программирования, как только программист уходит за рамки написания базовых вещей, и в настоящее время уже начинает казаться, что решение выбрать тот или иной язык для написания конкретных вещей зависит от A. Платформы, B. Изначальных потребностей компании, C. Стоимость программистов с нужными знаниями (или их обучением) на рынке, естественно D. Знаний/пожеланий участников команды разработки (порядок пунктов расположить в зависимости от пожеланий)
Вы пишите: *Если бы всё писали на С++, то было бы море вакансий* Вакансий действительно море.